Compare commits
174 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| e851c23488 | |||
| 9764a0845c | |||
| debe52834e | |||
| db4b4ccbaa | |||
| 90801c2a9a | |||
| e2ba785624 | |||
| 34b3331cea | |||
| bbaf0163b5 | |||
| 97cf15bdb2 | |||
| ee7253b3c1 | |||
| 2c52bc2a89 | |||
| 8e6ac13804 | |||
| 72bf8529a0 | |||
| fb996c1a8c | |||
| 166b50c003 | |||
| 023d9059df | |||
| ec2166013a | |||
| 0c43fa9c6a | |||
| 5fbc10d8fc | |||
| 36f8418cb5 | |||
| d393d8b8e0 | |||
| 323ff6e66a | |||
| 596a5ddb34 | |||
| 64ed4a38f2 | |||
| f1e7ec48ab | |||
| 3d084334b5 | |||
| 9e04461c01 | |||
| 5caf703b21 | |||
| 7602871600 | |||
| 9d39014d1e | |||
| ea32037620 | |||
| 44e4527719 | |||
| 298abf4608 | |||
| 0755463b00 | |||
| 38dc68b5af | |||
| 2b0f43cc39 | |||
| 0b82730ef9 | |||
| b4c2a3cc87 | |||
| 7a2cde87ad | |||
| 6031a10fa2 | |||
| b174ac5476 | |||
| a4123eefdb | |||
| 82245e3a3e | |||
| 1dc8c62c58 | |||
| 6efc90e87a | |||
| 6fd8cd9b5f | |||
| f4a75e51ae | |||
| 864b8a19db | |||
| 5c7cb0d272 | |||
| 52b7b3b82d | |||
| f9eed0480b | |||
| 0083395571 | |||
| 00819f92c7 | |||
| c10c45579f | |||
| caeef8dc53 | |||
| a9f157efda | |||
| 8c7ca25aea | |||
| 40188882d9 | |||
| 6fdc6ca853 | |||
| c0b1a38715 | |||
| 225e1825ac | |||
| d416835470 | |||
| ca8c9d0255 | |||
| 30b1610144 | |||
| 2c54762954 | |||
| 9373bfa5cd | |||
| b69e6e9419 | |||
| fc95b07c8c | |||
| 6596ccd7d7 | |||
| 0a87f3438f | |||
| 10d4d51815 | |||
| d3056f747f | |||
| 3216ab7e4f | |||
| f29e90852d | |||
| 7a3f10e765 | |||
| 89e8154e2e | |||
| c8002dc0ee | |||
| fb3f734739 | |||
| 8c794d7b47 | |||
| fa30779747 | |||
| 0c41870205 | |||
| a01d8ae9a0 | |||
| 9bdbfa4a23 | |||
| 7c2965d831 | |||
| 4900513982 | |||
| 0dc54aaf97 | |||
| ff8e35b1e4 | |||
| ec91559874 | |||
| 60be42bc1d | |||
| 3ae6ff5c69 | |||
| 393c50eafe | |||
| b81e26a516 | |||
| aa4e10ac3a | |||
| cea31c6c66 | |||
| 3a4039ffe7 | |||
| 36fed0d3ec | |||
| bf02b0879e | |||
| 6c0de11ea6 | |||
| fa3eeec98e | |||
| c9984fcc07 | |||
| a68d1926ea | |||
| a976e68bbe | |||
| 02570857a9 | |||
| 1120f6c4a1 | |||
| 9b126e67ca | |||
| 9370222ab3 | |||
| 24f9939187 | |||
| c9027de035 | |||
| 7dd73c1b14 | |||
| 002e889947 | |||
| 64b84216ee | |||
| 7d199a6618 | |||
| bd811a4452 | |||
| 3a6b33f20c | |||
| 0fe7e02304 | |||
| 69e7310ab3 | |||
| 2001ee8586 | |||
| 9c49825764 | |||
| 6faf46460e | |||
| 62b1e6c65c | |||
| e644d78807 | |||
| f0199b0003 | |||
| cd20abd2eb | |||
| d58e8f1563 | |||
| 5e674e94ec | |||
| fda8a89150 | |||
| e7f3b41da2 | |||
| 8d2fe94af9 | |||
| 01dd601c57 | |||
| b5a405cfba | |||
| 9f6d58c008 | |||
| 5f7b88ddc7 | |||
| b715a8a40f | |||
| 66e25732bf | |||
| fb9b30c426 | |||
| bb75088e81 | |||
| ae0b15615f | |||
| 3b21a7826b | |||
| a4d9736bfe | |||
| db3a74b95a | |||
| 00d1baf39d | |||
| d525853e7e | |||
| 73390344cf | |||
| a4da59c528 | |||
| 3707039c35 | |||
| 51409e3b85 | |||
| b391c94533 | |||
| 84b026a597 | |||
| 19d42170f7 | |||
| f4441522e1 | |||
| 977f11863c | |||
| 5235790a8e | |||
| 12bfa58335 | |||
| d65be15f1d | |||
| e1195a9f9b | |||
| d8dcce20ba | |||
| 384f5cedd5 | |||
| a9035ce017 | |||
| d39c847dc6 | |||
| b1ed6c0f16 | |||
| dfb85a051d | |||
| eb9c4c96e2 | |||
| 5d78092f1c | |||
| 63e791ef7e | |||
| 8491642a7e | |||
| 82648a53cf | |||
| 3ee6603927 | |||
| 01b38f51b5 | |||
| 446fe03555 | |||
| 00c99e3187 | |||
| ed7e215c22 | |||
| 5690f1b903 | |||
| 2004d28809 | |||
| 94eb0be0ec |
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: Support Request
|
||||
about: Support request or question relating to Kubernetes Website project
|
||||
about: Support request or question relating to Kubernetes Dashboard project
|
||||
labels:
|
||||
- triage/support
|
||||
---
|
||||
|
||||
@@ -1,12 +1,11 @@
|
||||
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
> Remember to delete this note before submitting your pull request.
|
||||
>
|
||||
> For pull requests on 1.18 Features: set Milestone to 1.18 and Base Branch to dev-1.18
|
||||
> For pull requests on 1.15 Features: set Milestone to 1.15 and Base Branch to dev-1.15
|
||||
>
|
||||
> For pull requests on Chinese localization, set Base Branch to release-1.14
|
||||
>
|
||||
> For pull requests on Chinese localization, set Base Branch to release-1.16
|
||||
> Feel free to ask questions in #kubernetes-docs-zh
|
||||
>
|
||||
> For pull requests on Korean Localization: set Base Branch to dev-1.16-ko.\<latest team milestone>
|
||||
> For pull requests on Korean Localization: set Base Branch to dev-1.14-ko.\<latest team milestone>
|
||||
>
|
||||
> If you need Help on editing and submitting pull requests, visit:
|
||||
> https://kubernetes.io/docs/contribute/start/#improve-existing-content.
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
FROM alpine:latest
|
||||
|
||||
LABEL maintainer="Luc Perkins <lperkins@linuxfoundation.org>"
|
||||
MAINTAINER Luc Perkins <lperkins@linuxfoundation.org>
|
||||
|
||||
RUN apk add --no-cache \
|
||||
curl \
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
DOCKER = docker
|
||||
HUGO_VERSION = 0.59.1
|
||||
HUGO_VERSION = 0.58.3
|
||||
DOCKER_IMAGE = kubernetes-hugo
|
||||
DOCKER_RUN = $(DOCKER) run --rm --interactive --tty --volume $(CURDIR):/src
|
||||
NODE_BIN = node_modules/.bin
|
||||
|
||||
@@ -6,11 +6,5 @@ reviewers:
|
||||
approvers:
|
||||
- sig-docs-en-owners # Defined in OWNERS_ALIASES
|
||||
|
||||
emeritus_approvers:
|
||||
- chenopis
|
||||
- jaredbhatti
|
||||
# stewart-yu, you're welcome to return when you're ready to resume PR wrangling
|
||||
- stewart-yu
|
||||
|
||||
labels:
|
||||
- sig/docs
|
||||
@@ -3,11 +3,13 @@ aliases:
|
||||
- timothysc
|
||||
- lukemarsden
|
||||
- luxas
|
||||
- roberthbailey
|
||||
- fabriziopandini
|
||||
sig-cluster-lifecycle-kubeadm-reviewers: # Reviewing kubeadm documentation
|
||||
- timothysc
|
||||
- lukemarsden
|
||||
- luxas
|
||||
- roberthbailey
|
||||
- fabriziopandini
|
||||
- kad
|
||||
- xiangpengzhao
|
||||
@@ -16,21 +18,6 @@ aliases:
|
||||
- chuckha
|
||||
- detiber
|
||||
- dixudx
|
||||
sig-docs-blog-owners: # Approvers for blog content
|
||||
- castrojo
|
||||
- kbarnard10
|
||||
- onlydole
|
||||
- zacharysarah
|
||||
- mrbobbytables
|
||||
sig-docs-blog-reviewers: # Reviewers for blog content
|
||||
- castrojo
|
||||
- cody-clark
|
||||
- kbarnard10
|
||||
- mrbobbytables
|
||||
- onlydole
|
||||
- parispittman
|
||||
- vonguard
|
||||
- onlydole
|
||||
sig-docs-de-owners: # Admins for German content
|
||||
- bene2k1
|
||||
- mkorbi
|
||||
@@ -42,48 +29,35 @@ aliases:
|
||||
sig-docs-en-owners: # Admins for English content
|
||||
- bradamant3
|
||||
- bradtopol
|
||||
- daminisatya
|
||||
- gochist
|
||||
- chenopis
|
||||
- cody-clark
|
||||
- jaredbhatti
|
||||
- jimangel
|
||||
- kbarnard10
|
||||
- kbhawkey
|
||||
- makoscafee
|
||||
- Rajakavitha1
|
||||
- ryanmcginnis
|
||||
- sftim
|
||||
- simplytunde
|
||||
- steveperry-53
|
||||
- tengqm
|
||||
- xiangpengzhao
|
||||
- zacharysarah
|
||||
- zparnold
|
||||
sig-docs-en-reviews: # PR reviews for English content
|
||||
- bradamant3
|
||||
- bradtopol
|
||||
- daminisatya
|
||||
- gochist
|
||||
- jaredbhatti
|
||||
- jimangel
|
||||
- kbarnard10
|
||||
- kbhawkey
|
||||
- makoscafee
|
||||
- mistyhacks
|
||||
- rajakavitha1
|
||||
- ryanmcginnis
|
||||
- sftim
|
||||
- simplytunde
|
||||
- steveperry-53
|
||||
- stewart-yu
|
||||
- tengqm
|
||||
- xiangpengzhao
|
||||
- tfogo
|
||||
- zacharysarah
|
||||
- zhangxiaoyu-zidif
|
||||
- zparnold
|
||||
sig-docs-en-reviews: # PR reviews for English content
|
||||
- jimangel
|
||||
- rajakavitha1
|
||||
- stewart-yu
|
||||
- xiangpengzhao
|
||||
- zhangxiaoyu-zidif
|
||||
sig-docs-es-owners: # Admins for Spanish content
|
||||
- raelga
|
||||
- alexbrand
|
||||
sig-docs-es-reviews: # PR reviews for Spanish content
|
||||
- raelga
|
||||
- alexbrand
|
||||
# glo-pena
|
||||
- glo-pena
|
||||
- electrocucaracha
|
||||
sig-docs-fr-owners: # Admins for French content
|
||||
- remyleone
|
||||
@@ -126,53 +100,53 @@ aliases:
|
||||
- girikuncoro
|
||||
- irvifa
|
||||
sig-docs-it-owners: # Admins for Italian content
|
||||
- fabriziopandini
|
||||
- mattiaperi
|
||||
- micheleberardi
|
||||
- rlenferink
|
||||
- micheleberardi
|
||||
sig-docs-it-reviews: # PR reviews for Italian content
|
||||
- fabriziopandini
|
||||
- mattiaperi
|
||||
- micheleberardi
|
||||
- rlenferink
|
||||
sig-docs-ja-owners: # Admins for Japanese content
|
||||
- micheleberardi
|
||||
sig-docs-ja-owners: # Admins for Japanese content
|
||||
- cstoku
|
||||
- inductor
|
||||
- nasa9084
|
||||
sig-docs-ja-reviews: # PR reviews for Japanese content
|
||||
- tnir
|
||||
- zacharysarah
|
||||
sig-docs-ja-reviews: # PR reviews for Japanese content
|
||||
- cstoku
|
||||
- inductor
|
||||
- makocchi-git
|
||||
- MasayaAoyama
|
||||
- nasa9084
|
||||
- oke-py
|
||||
- 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
|
||||
- gochist
|
||||
- ianychoi
|
||||
- seokho-son
|
||||
- ysyukr
|
||||
sig-docs-maintainers: # Website maintainers
|
||||
- bradamant3
|
||||
- chenopis
|
||||
- jaredbhatti
|
||||
- jimangel
|
||||
- kbarnard10
|
||||
- mistyhacks
|
||||
- pwittrock
|
||||
- steveperry-53
|
||||
- tengqm
|
||||
- zacharysarah
|
||||
- zparnold
|
||||
sig-docs-zh-owners: # Admins for Chinese content
|
||||
- bradtopol
|
||||
- chenopis
|
||||
- chenrui333
|
||||
- dchen1107
|
||||
- haibinxie
|
||||
- hanjiayao
|
||||
- lichuqiang
|
||||
- lucperkins
|
||||
- markthink
|
||||
- SataQiu
|
||||
- tengqm
|
||||
@@ -193,26 +167,6 @@ aliases:
|
||||
sig-docs-pt-owners: # Admins for Portuguese content
|
||||
- femrtnz
|
||||
- jcjesus
|
||||
- devlware
|
||||
sig-docs-pt-reviews: # PR reviews for Portugese content
|
||||
- femrtnz
|
||||
- jcjesus
|
||||
- devlware
|
||||
sig-docs-vi-owners: # Admins for Vietnamese content
|
||||
- huynguyennovem
|
||||
- ngtuna
|
||||
- truongnh1992
|
||||
sig-docs-vi-reviews: # PR reviews for Vietnamese content
|
||||
- huynguyennovem
|
||||
- ngtuna
|
||||
- truongnh1992
|
||||
sig-docs-ru-owners: # Admins for Russian content
|
||||
- msheldyakov
|
||||
- aisonaku
|
||||
- potapy4
|
||||
- dianaabv
|
||||
sig-docs-ru-reviews: # PR reviews for Russian content
|
||||
- msheldyakov
|
||||
- aisonaku
|
||||
- potapy4
|
||||
- dianaabv
|
||||
|
||||
@@ -1,75 +0,0 @@
|
||||
# Kubernetesのドキュメント
|
||||
|
||||
[](https://travis-ci.org/kubernetes/website)
|
||||
[](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サイトおよびドキュメンテーションへの皆さんの貢献に感謝します!
|
||||
@@ -3,13 +3,13 @@
|
||||
[](https://travis-ci.org/kubernetes/website)
|
||||
[](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`
|
||||
|
||||
@@ -44,13 +44,13 @@
|
||||
make docker-image
|
||||
```
|
||||
|
||||
해당 이미지가 빌드 된 이후, 사이트를 로컬에서 실행할 수 있습니다:
|
||||
해당 이미지가 빌드된 이후, 사이트를 로컬에서 실행할 수 있습니다:
|
||||
|
||||
```bash
|
||||
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는 사이트를 업데이트하고 브라우저를 강제로 새로고침합니다.
|
||||
|
||||
## 감사합니다!
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ Bem vindos! Este repositório abriga todos os recursos necessários para criar o
|
||||
|
||||
Você pode clicar no botão **Fork** na área superior direita da tela para criar uma cópia desse repositório na sua conta do GitHub. Esta cópia é chamada de *fork*. Faça as alterações desejadas no seu fork e, quando estiver pronto para enviar as alterações para nós, vá até o fork e crie uma nova solicitação de pull para nos informar sobre isso.
|
||||
|
||||
Depois que seu **pull request** for criado, um revisor do Kubernetes assumirá a responsabilidade de fornecer um feedback claro e objetivo. Como proprietário do pull request, **é sua responsabilidade modificar seu pull request para abordar o feedback que foi fornecido a você pelo revisor do Kubernetes.** Observe também que você pode acabar tendo mais de um revisor do Kubernetes para fornecer seu feedback ou você pode acabar obtendo feedback de um revisor do Kubernetes que é diferente daquele originalmente designado para lhe fornecer feedback. Além disso, em alguns casos, um de seus revisores pode solicitar uma revisão técnica de um [revisor de tecnologia Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) quando necessário. Os revisores farão o melhor para fornecer feedback em tempo hábil, mas o tempo de resposta pode variar de acordo com as circunstâncias.
|
||||
Depois que seu **pull request** for criada, um revisor do Kubernetes assumirá a responsabilidade de fornecer um feedback claro e objetivo. Como proprietário do pull request, **é sua responsabilidade modificar seu pull request para abordar o feedback que foi fornecido a você pelo revisor do Kubernetes.** Observe também que você pode acabar tendo mais de um revisor do Kubernetes para fornecer seu feedback ou você pode acabar obtendo feedback de um revisor do Kubernetes que é diferente daquele originalmente designado para lhe fornecer feedback. Além disso, em alguns casos, um de seus revisores pode solicitar uma revisão técnica de um [revisor de tecnologia Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) quando necessário. Os revisores farão o melhor para fornecer feedback em tempo hábil, mas o tempo de resposta pode variar de acordo com as circunstâncias.
|
||||
|
||||
Para mais informações sobre como contribuir com a documentação do Kubernetes, consulte:
|
||||
|
||||
@@ -19,10 +19,16 @@ 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/)
|
||||
|
||||
Você pode contactar os mantenedores da localização em Português em:
|
||||
## Documentação do Kubernetes Localizando o `README.md`
|
||||
|
||||
* Felipe ([GitHub - @femrtnz](https://github.com/femrtnz))
|
||||
* [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-pt)
|
||||
### 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)
|
||||
|
||||
## Executando o site localmente usando o Docker
|
||||
|
||||
@@ -62,7 +68,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 falar com os mantenedores deste projeto:
|
||||
Você pode alcançar os mantenedores deste projeto em:
|
||||
|
||||
- [Slack](https://kubernetes.slack.com/messages/sig-docs)
|
||||
- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
|
||||
@@ -73,4 +79,4 @@ A participação na comunidade Kubernetes é regida pelo [Código de Conduta da
|
||||
|
||||
## Obrigado!
|
||||
|
||||
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!
|
||||
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!
|
||||
|
||||
@@ -1,80 +0,0 @@
|
||||
# Документация по Kubernetes
|
||||
|
||||
[](https://travis-ci.org/kubernetes/website)
|
||||
[](https://github.com/kubernetes/website/releases/latest)
|
||||
|
||||
Добро пожаловать! Данный репозиторий содержит все необходимые файлы для сборки [сайта Kubernetes и документации](https://kubernetes.io/). Мы благодарим вас за старания!
|
||||
|
||||
## Вклад в документацию
|
||||
|
||||
Нажмите на кнопку **Fork** в правом верхнем углу, чтобы создать копию этого репозитория в ваш GitHub-аккаунт. Это копия называется *форк-репозиторием*. Делайте любые изменения в вашем форк-репозитории, и когда вы будете готовы опубликовать изменения, откройте форк-репозиторий и создайте новый пулреквест, чтобы уведомить нас.
|
||||
|
||||
После того, как вы отправите пулреквест, ревьювер Kubernetes даст по нему обратную связь. Вы, как автор пулреквеста, **должны обновить свой пулреквест после его рассмотрения ревьювером Kubernetes.** Вполне возможно, что более одного ревьювера Kubernetes оставят свои комментарии или даже может быть так, что новый комментарий ревьювера Kubernetes будет отличаться от первоначального назначенного ревьювера. Кроме того, в некоторых случаях один из ревьюверов может запросить технический обзор у [технического ревьювера Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers), если это будет необходимо. Ревьюверы сделают все возможное, чтобы как можно оперативно оставить свои предложения и пожелания, но время ответа может варьироваться в зависимости от обстоятельств.
|
||||
|
||||
Узнать подробнее о том, как поучаствовать в документации Kubernetes, вы можете по ссылкам ниже:
|
||||
|
||||
* [Начните вносить свой вклад](https://kubernetes.io/docs/contribute/start/)
|
||||
* [Просмотр локальных изменений](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
|
||||
* [Использование шаблонов страниц](http://kubernetes.io/docs/contribute/style/page-templates/)
|
||||
* [Руководство по оформлению документации](http://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [Руководство по локализации Kubernetes](https://kubernetes.io/docs/contribute/localization/)
|
||||
|
||||
## Файл `README.md` на других языках
|
||||
| | |
|
||||
|-------------------------------|-------------------------------|
|
||||
| [Французский](README-fr.md) | [Корейский](README-ko.md) |
|
||||
| [Немецкий](README-de.md) | [Португальский](README-pt.md) |
|
||||
| [Хинди](README-hi.md) | [Испанский](README-es.md) |
|
||||
| [Индонезийский](README-id.md) | [Китайский](README-zh.md) |
|
||||
| | |
|
||||
|
||||
## Запуск сайта локально с помощью Docker
|
||||
|
||||
Рекомендованный способ запуска сайта Kubernetes на локальной машине - использовать специальный образ [Docker](https://docker.com), который включает статический генератор сайтов [Hugo](https://gohugo.io).
|
||||
|
||||
> Если вы используете Windows, вам необходимо установить дополнительные инструменты через [Chocolatey](https://chocolatey.org). `choco install make`
|
||||
|
||||
> Если вы хотите запустить сайт локально без Docker, обратитесь к разделу [Запуск сайта с помощью Hugo](#running-the-site-locally-using-hugo) ниже на этой странице.
|
||||
|
||||
Когда Docker [установлен и запущен](https://www.docker.com/get-started), соберите локально Docker-образ `kubernetes-hugo`, выполнив команду в консоли:
|
||||
|
||||
```bash
|
||||
make docker-image
|
||||
```
|
||||
|
||||
После того, как вы собрали образ, можно запустить сайт локально:
|
||||
|
||||
```bash
|
||||
make docker-serve
|
||||
```
|
||||
|
||||
Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайт. Если вы редактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере.
|
||||
|
||||
## Запуск сайта с помощью Hugo {#running-the-site-locally-using-hugo}
|
||||
|
||||
Обратитесь к [официальной документации Hugo](https://gohugo.io/getting-started/installing/), чтобы установить Hugo. Убедитесь, что вы установили правильную версию Hugo, которая устанавливается в переменной окружения `HUGO_VERSION` в файле [`netlify.toml`](netlify.toml#L9).
|
||||
|
||||
После установки Hugo, чтобы запустить сайт, выполните в консоли:
|
||||
|
||||
```bash
|
||||
make serve
|
||||
```
|
||||
|
||||
Эта команда запустит сервер Hugo на порту 1313. Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайта. Если вы отредактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере.
|
||||
|
||||
## Сообщество, обсуждение, вклад и поддержка
|
||||
|
||||
Узнайте, как поучаствовать в жизни сообщества Kubernetes на [странице сообщества](http://kubernetes.io/community/).
|
||||
|
||||
Вы можете связаться с сопровождающими этого проекта по следующим ссылкам:
|
||||
|
||||
- [Канал в Slack](https://kubernetes.slack.com/messages/sig-docs)
|
||||
- [Рассылка](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
|
||||
|
||||
### Нормы поведения
|
||||
|
||||
Участие в сообществе Kubernetes регулируется [нормами поведения Kubernetes](code-of-conduct.md).
|
||||
|
||||
## Спасибо!
|
||||
|
||||
Kubernetes процветает благодаря сообществу и мы ценим ваш вклад в сайт и документацию!
|
||||
@@ -1,72 +0,0 @@
|
||||
# Tài liệu Kubernetes
|
||||
|
||||
[](https://travis-ci.org/kubernetes/website)
|
||||
[](https://github.com/kubernetes/website/releases/latest)
|
||||
|
||||
Chào mừng! Kho lưu trữ này chứa tất cả các tài nguyên cần thiết để xây dựng [trang web của Kubernetes và các tài liệu](https://kubernetes.io/). Chúng tôi rất vui vì bạn muốn đóng góp.
|
||||
|
||||
## Đóng góp cho tài liệu
|
||||
|
||||
Bạn có thể click vào nút **Fork** ở góc trên bên phải màn hình để tạo bản sao của kho lưu trữ này trong tài khoản GitHub của bạn. Bản sao này được gọi là một bản *fork*. Thực hiện bất kì thay đổi nào mà bạn muốn trong bản fork của bạn và khi bạn sẵn sang gửi những thay đổi đó cho chúng tôi, hãy đến bản fork của bạn và tạo một Pull Request mới để cho chúng tôi biết về nó.
|
||||
|
||||
Một khi Pull Request của bạn được tạo, reviewer sẽ chịu trách nhiệm cung cấp các phản hồi rõ ràng, có thể thực hiện được. Là chủ sở hữu của pull request, **bạn có trách nhiệm sửa đổi Pull Request của mình để giải quyết các phản hồi bởi reviewer.** Ngoài ra, lưu ý rằng bạn có thể có nhiều hơn một reviewer cung cấp cho bạn các phản hồi hoặc bạn có thể nhận được phản hồi từ reviewer khác với reviewer ban đầu được chỉ định. Hơn nữa, trong một số trường hợp, một trong những reviewer của bạn có thể yêu cầu đánh giá kỹ thuật từ [Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers) khi cần. Các reviewers sẽ cố gắng hết sức để cung cấp phản hồi một cách kịp thời nhưng thời gian phản hồi có thể thay đổi tùy theo hoàn cảnh.
|
||||
|
||||
Để biết thêm thông tin về việc đóng góp cho tài liệu Kubernetes, hãy xem:
|
||||
|
||||
* [Bắt đầu đóng góp](https://kubernetes.io/docs/contribute/start/)
|
||||
* [Các giai đoạn thay đổi tài liệu](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
|
||||
* [Sử dụng các trang templates](http://kubernetes.io/docs/contribute/style/page-templates/)
|
||||
* [Hướng dẫn biểu mẫu tài liệu](http://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [Địa phương hóa tài liệu Kubernetes](https://kubernetes.io/docs/contribute/localization/)
|
||||
|
||||
|
||||
## Chạy website cục bộ dùng Docker
|
||||
|
||||
Cách được đề xuất để chạy trang web Kubernetes cục bộ là dùng [Docker](https://docker.com) image chứa trình tạo web tĩnh [Hugo](https://gohugo.io).
|
||||
|
||||
> Nếu bạn làm việc trên môi trường Windows, bạn sẽ cần thêm môt vài công cụ mà bạn có thể cài đặt với [Chocolatey](https://chocolatey.org). `choco install make`
|
||||
|
||||
> Nếu bạn không muốn dùng Docker để chạy trang web cục bộ, hãy xem [Chạy website cục bộ dùng Hugo](#Chạy website cục bộ dùng Hugo) dưới đây.
|
||||
|
||||
Nếu bạn có Docker đang [up và running](https://www.docker.com/get-started), build `kubernetes-hugo` Docker image cục bộ:
|
||||
|
||||
```bash
|
||||
make docker-image
|
||||
```
|
||||
|
||||
Khi image đã được built, bạn có thể chạy website cục bộ:
|
||||
|
||||
```bash
|
||||
make docker-serve
|
||||
```
|
||||
|
||||
Mở trình duyệt và đến địa chỉ http://localhost:1313 để xem website. Khi bạn thay đổi các file nguồn, Hugo cập nhật website và buộc làm mới trình duyệt.
|
||||
|
||||
## Chạy website cục bộ dùng Hugo
|
||||
|
||||
Hãy xem [tài liệu chính thức của Hugo](https://gohugo.io/getting-started/installing/) cho việc hướng dẫn cài đặt Hugo. Đảm bảo cài đặt phiên bản mở rộng của Hugo được xác định bởi biến môi trường `HUGO_VERSION` trong file [`netlify.toml`](netlify.toml#L9)
|
||||
|
||||
Để chạy website cục bộ khi Hugo được cài đặt:
|
||||
|
||||
```bash
|
||||
make serve
|
||||
```
|
||||
|
||||
Câu lệnh trên sẽ khởi động server Hugo cục bộ trên cổng 1313. Mở trình duyệt và đến địa chỉ http://localhost:1313 để xem website. Khi bạn thay đổi các file nguồn, Hugo cập nhật website và buộc làm mới trình duyệt.
|
||||
|
||||
## Cộng đồng, thảo luận, đóng góp và hỗ trợ
|
||||
|
||||
Tìm hiểu cách tham gia với cộng đồng Kubernetes trên [trang cộng đồng](http://kubernetes.io/community/).
|
||||
|
||||
Bạn có thể tiếp cận những maintainers của dự án này tại:
|
||||
|
||||
- [Slack](https://kubernetes.slack.com/messages/sig-docs)
|
||||
- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
|
||||
|
||||
### Quy tắc ứng xử
|
||||
|
||||
Sự tham gia vào cộng đồng Kubernetes được điểu chỉnh bởi [Kubernetes Code of Conduct](code-of-conduct.md).
|
||||
|
||||
## Cảm ơn!
|
||||
|
||||
Kubernetes phát triển mạnh mẽ về sự tham gia của cộng đồng và chúng tôi đánh giá cao những đóng góp của bạn cho trang web và tài liệu của chúng tôi!
|
||||
@@ -1,182 +0,0 @@
|
||||
# Kubernetes 文档
|
||||
<!--
|
||||
# The Kubernetes documentation
|
||||
-->
|
||||
|
||||
[](https://travis-ci.org/kubernetes/website)
|
||||
[](https://github.com/kubernetes/website/releases/latest)
|
||||
|
||||
<!--
|
||||
Welcome! This repository houses all of the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/).
|
||||
We're glad that you want to contribute!
|
||||
-->
|
||||
欢迎!本仓库包含了所有用于构建 [Kubernetes 网站和文档](https://kubernetes.io/)的内容。
|
||||
我们非常高兴您想要参与贡献!
|
||||
|
||||
<!--
|
||||
## Contributing to the docs
|
||||
-->
|
||||
## 贡献文档
|
||||
|
||||
<!--
|
||||
You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account.
|
||||
This copy is called a *fork*. Make any changes you want in your fork,
|
||||
and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it.
|
||||
-->
|
||||
您可以点击屏幕右上方的 **Fork** 按钮,在您的 GitHub 账户下创建一份本仓库的副本。这个副本叫做 *fork*。您可以对 fork 副本进行任意修改,
|
||||
当准备好把修改提交给我们时,您可以通过创建一个 pull request 来告知我们。
|
||||
|
||||
<!--
|
||||
Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback.
|
||||
As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.**
|
||||
Also, note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one initially assigned to provide you feedback.
|
||||
Furthermore, in some cases, one of your reviewers might ask for a technical review from a [Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers) when needed.
|
||||
Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.
|
||||
-->
|
||||
创建 pull request 后,Kubernetes 审核人员将负责提供清晰且可操作的反馈。作为 pull request 的所有者,**您有责任修改 pull request 以解决 Kubernetes 审核者提供给您的反馈。**
|
||||
另请注意,您最终可能会收到多个 Kubernetes 审核人员为您提供的反馈,也可能出现后面 Kubernetes 审核人员的反馈与前面审核人员的反馈不尽相同的情况。
|
||||
此外,在某些情况下,您的某位评审员可能会在需要时要求 [Kubernetes 技术评审员](https://github.com/kubernetes/website/wiki/Tech-reviewers) 进行技术评审。
|
||||
审稿人将尽最大努力及时提供反馈,但响应时间可能因情况而异。
|
||||
|
||||
<!--
|
||||
For more information about contributing to the Kubernetes documentation, see:
|
||||
|
||||
* [Start contributing](https://kubernetes.io/docs/contribute/start/)
|
||||
* [Staging Your Documentation Changes](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
|
||||
* [Using Page Templates](http://kubernetes.io/docs/contribute/style/page-templates/)
|
||||
* [Documentation Style Guide](http://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)
|
||||
-->
|
||||
有关为 Kubernetes 文档做出贡献的更多信息,请参阅:
|
||||
|
||||
* [开始贡献](https://kubernetes.io/docs/contribute/start/)
|
||||
* [缓存您的文档变更](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
|
||||
* [使用页面模版](http://kubernetes.io/docs/contribute/style/page-templates/)
|
||||
* [文档风格指南](http://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [本地化 Kubernetes 文档](https://kubernetes.io/docs/contribute/localization/)
|
||||
|
||||
<!--
|
||||
## `README.md`'s Localizing Kubernetes Documentation
|
||||
-->
|
||||
## `README.md` 的本地化 Kubernetes 文档
|
||||
|
||||
<!--
|
||||
### Korean
|
||||
|
||||
You can reach the maintainers of Korean localization at:
|
||||
|
||||
* June Yi ([GitHub - @gochist](https://github.com/gochist))
|
||||
* [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-ko)
|
||||
-->
|
||||
### 中文
|
||||
|
||||
可以通过以下方式联系中文本地化的维护人员:
|
||||
|
||||
* Rui Chen ([GitHub - @chenrui333](https://github.com/chenrui333))
|
||||
* He Xiaolong ([GitHub - @markthink](https://github.com/markthink))
|
||||
* [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-zh)
|
||||
|
||||
<!--
|
||||
## Running the website locally using Docker
|
||||
-->
|
||||
## 在本地使用 docker 运行网站
|
||||
|
||||
<!--
|
||||
The recommended way to run the Kubernetes website locally is to run a specialized [Docker](https://docker.com) image that includes the [Hugo](https://gohugo.io) static website generator.
|
||||
-->
|
||||
在本地运行 Kubernetes 网站的推荐方法是运行包含 [Hugo](https://gohugo.io) 静态网站生成器的专用 [Docker](https://docker.com) 镜像。
|
||||
|
||||
<!--
|
||||
> If you are running on Windows, you'll need a few more tools which you can install with [Chocolatey](https://chocolatey.org). `choco install make`
|
||||
-->
|
||||
> 如果您使用的是 Windows,则需要一些工具,可以使用 [Chocolatey](https://chocolatey.org) 进行安装。`choco install make`
|
||||
|
||||
<!--
|
||||
> If you'd prefer to run the website locally without Docker, see [Running the website locally using Hugo](#running-the-site-locally-using-hugo) below.
|
||||
-->
|
||||
> 如果您更喜欢在没有 Docker 的情况下在本地运行网站,请参阅下面的[使用 Hugo 在本地运行网站](#running-the-site-locally-using-hugo) 章节。
|
||||
|
||||
<!--
|
||||
If you have Docker [up and running](https://www.docker.com/get-started), build the `kubernetes-hugo` Docker image locally:
|
||||
-->
|
||||
如果您已经[安装运行](https://www.docker.com/get-started)了 Docker,使用以下命令在本地构建 `kubernetes-hugo` Docker 镜像:
|
||||
|
||||
```bash
|
||||
make docker-image
|
||||
```
|
||||
|
||||
<!--
|
||||
Once the image has been built, you can run the website locally:
|
||||
-->
|
||||
一旦创建了镜像,您就可以在本地运行网站了:
|
||||
|
||||
```bash
|
||||
make docker-serve
|
||||
```
|
||||
|
||||
<!--
|
||||
Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
|
||||
-->
|
||||
打开浏览器访问 http://localhost:1313 以查看网站。当您对源文件进行更改时,Hugo 会更新网站并强制刷新浏览器。
|
||||
|
||||
<!--
|
||||
## Running the website locally using Hugo
|
||||
-->
|
||||
## 使用 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.
|
||||
-->
|
||||
有关 Hugo 的安装说明,请参阅 [Hugo 官方文档](https://gohugo.io/getting-started/installing/)。
|
||||
确保安装对应版本的 Hugo,版本号由 [`netlify.toml`](netlify.toml#L9) 文件中的 `HUGO_VERSION` 环境变量指定。
|
||||
|
||||
<!--
|
||||
To run the website locally when you have Hugo installed:
|
||||
-->
|
||||
安装 Hugo 后,在本地运行网站:
|
||||
|
||||
```bash
|
||||
make serve
|
||||
```
|
||||
|
||||
<!--
|
||||
This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
|
||||
-->
|
||||
这将在 1313 端口上启动本地 Hugo 服务器。打开浏览器访问 http://localhost:1313 查看网站。当您对源文件进行更改时,Hugo 会更新网站并强制刷新浏览器。
|
||||
|
||||
<!--
|
||||
## Community, discussion, contribution, and support
|
||||
-->
|
||||
## 社区、讨论、贡献和支持
|
||||
|
||||
<!--
|
||||
Learn how to engage with the Kubernetes community on the [community page](http://kubernetes.io/community/).
|
||||
-->
|
||||
在[社区页面](http://kubernetes.io/community/)了解如何与 Kubernetes 社区互动。
|
||||
|
||||
<!--
|
||||
You can reach the maintainers of this project at:
|
||||
-->
|
||||
您可以通过以下方式联系该项目的维护人员:
|
||||
|
||||
- [Slack](https://kubernetes.slack.com/messages/sig-docs)
|
||||
- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
|
||||
|
||||
<!--
|
||||
### Code of conduct
|
||||
|
||||
Participation in the Kubernetes community is governed by the [Kubernetes Code of Conduct](code-of-conduct.md).
|
||||
-->
|
||||
### 行为准则
|
||||
|
||||
参与 Kubernetes 社区受 [Kubernetes 行为准则](code-of-conduct.md)的约束。
|
||||
|
||||
<!--
|
||||
## Thank you!
|
||||
|
||||
Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation!
|
||||
-->
|
||||
## 感谢!
|
||||
|
||||
Kubernetes 因为社区的参与而蓬勃发展,感谢您对我们网站和文档的贡献!
|
||||
@@ -25,9 +25,7 @@ For more information about contributing to the Kubernetes documentation, see:
|
||||
|[French README](README-fr.md)|[Korean README](README-ko.md)|
|
||||
|[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)|[Vietnamese README](README-vi.md)|
|
||||
|[Russian README](README-ru.md)|
|
||||
|[Indonesian README](README-id.md)|
|
||||
|||
|
||||
|
||||
## Running the website locally using Docker
|
||||
@@ -54,7 +52,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 extended 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 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:
|
||||
|
||||
|
||||
@@ -10,6 +10,6 @@
|
||||
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE
|
||||
# INSTRUCTIONS AT https://kubernetes.io/security/
|
||||
|
||||
chenopis
|
||||
bradamant3
|
||||
jimangel
|
||||
zacharysarah
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
# See the OWNERS docs at https://go.k8s.io/owners
|
||||
|
||||
# Allow CSS/SASS updates from blog and case studies owners
|
||||
options:
|
||||
no_parent_owners: false
|
||||
reviewers:
|
||||
- alexcontini
|
||||
approvers:
|
||||
- alexcontini
|
||||
|
||||
@@ -70,7 +70,7 @@ section
|
||||
background-color: white
|
||||
|
||||
section, header, footer
|
||||
.main-section
|
||||
main
|
||||
position: relative
|
||||
margin: auto
|
||||
|
||||
@@ -126,10 +126,6 @@ header
|
||||
background-position: center center
|
||||
background-repeat: no-repeat
|
||||
|
||||
#blog
|
||||
&.flip-nav, &.open-nav
|
||||
.logo
|
||||
background-image: url(../images/nav_logo2.svg)
|
||||
|
||||
// Blog post tables
|
||||
.blog-content
|
||||
@@ -249,7 +245,7 @@ header
|
||||
color: $blue
|
||||
font-weight: normal
|
||||
|
||||
.main-section
|
||||
main
|
||||
white-space: nowrap
|
||||
overflow: hidden
|
||||
clear: both
|
||||
@@ -439,7 +435,7 @@ footer
|
||||
background-image: url(/images/texture.png)
|
||||
background-color: $dark-grey
|
||||
|
||||
.main-section
|
||||
main
|
||||
padding: 20px 0
|
||||
|
||||
nav
|
||||
@@ -488,9 +484,9 @@ footer
|
||||
|
||||
.social a
|
||||
display: inline-block
|
||||
background-image: url(/images/social_sprite.svg)
|
||||
background-image: url(/images/social_sprite.png)
|
||||
background-repeat: no-repeat
|
||||
background-size: 350px
|
||||
background-size: auto
|
||||
width: 50px
|
||||
height: 50px
|
||||
border-radius: 5px
|
||||
@@ -549,12 +545,6 @@ a.calendar
|
||||
&:hover
|
||||
background-position: -250px 100%
|
||||
|
||||
a.youtube
|
||||
background-position: -300px 0
|
||||
|
||||
&:hover
|
||||
background-position: -300px 100%
|
||||
|
||||
#viewDocs
|
||||
display: none
|
||||
|
||||
@@ -900,6 +890,7 @@ dd
|
||||
font-family: $mono-font
|
||||
vertical-align: baseline
|
||||
font-size: 14px
|
||||
font-weight: bold
|
||||
padding: 2px 4px
|
||||
|
||||
a code
|
||||
@@ -1071,7 +1062,7 @@ dd
|
||||
position: fixed
|
||||
bottom: 0
|
||||
|
||||
.miceType
|
||||
#miceType
|
||||
clear: both
|
||||
font-size: 11px
|
||||
line-height: 18px
|
||||
@@ -1127,23 +1118,13 @@ $feature-box-div-margin-bottom: 40px
|
||||
margin-bottom: 0
|
||||
padding-bottom: 1px
|
||||
|
||||
.main-section
|
||||
main
|
||||
padding: 0 10px
|
||||
margin-bottom: 30px
|
||||
|
||||
#vendorStrip
|
||||
display: none
|
||||
|
||||
// Add logo to CNCF section
|
||||
section#cncf
|
||||
padding-top: 60px
|
||||
padding-bottom: 140px
|
||||
background-image: url(/images/cncf-color.svg)
|
||||
background-position: center 100px
|
||||
background-repeat: no-repeat
|
||||
background-size: 300px
|
||||
|
||||
|
||||
|
||||
// OCEAN NODES
|
||||
#oceanNodes
|
||||
@@ -1153,7 +1134,7 @@ $feature-box-div-margin-bottom: 40px
|
||||
a
|
||||
color: $blue
|
||||
|
||||
.main-section
|
||||
main
|
||||
margin-bottom: $ocean-nodes-padding-Y
|
||||
min-height: 160px
|
||||
|
||||
@@ -1166,7 +1147,7 @@ $feature-box-div-margin-bottom: 40px
|
||||
width: 100%
|
||||
max-width: 160px
|
||||
|
||||
.main-section:first-child
|
||||
main:first-child
|
||||
.image-wrapper
|
||||
max-width: 100%
|
||||
|
||||
@@ -1193,7 +1174,7 @@ $feature-box-div-margin-bottom: 40px
|
||||
position: absolute
|
||||
top: 50%
|
||||
left: 75%
|
||||
width: 575px
|
||||
width: 525px
|
||||
padding-right: 80px
|
||||
transform: translate(-50%, -50%)
|
||||
color: white
|
||||
@@ -1288,6 +1269,15 @@ $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
|
||||
@@ -1314,10 +1304,10 @@ $feature-box-div-margin-bottom: 40px
|
||||
#features
|
||||
padding-top: 140px
|
||||
background-color: $light-grey
|
||||
background-image: url(/images/wheel.svg)
|
||||
background-image: url(/images/wheel.png)
|
||||
background-position: center 60px
|
||||
background-repeat: no-repeat
|
||||
background-size: 60px
|
||||
background-size: auto
|
||||
|
||||
.feature-box
|
||||
//padding: 50px 0
|
||||
@@ -1362,7 +1352,7 @@ $feature-box-div-margin-bottom: 40px
|
||||
#mainContent
|
||||
padding: 20px 0
|
||||
|
||||
.main-section
|
||||
main
|
||||
max-width: none
|
||||
|
||||
a
|
||||
@@ -1781,7 +1771,7 @@ $feature-box-div-margin-bottom: 40px
|
||||
|
||||
#home
|
||||
#talkToUs
|
||||
.main-section
|
||||
main
|
||||
padding: 30px 0
|
||||
|
||||
h5
|
||||
|
||||
@@ -95,7 +95,7 @@ $video-section-height: 550px
|
||||
right: -25px
|
||||
|
||||
section, header, footer
|
||||
.main-section
|
||||
main
|
||||
max-width: $main-max-width
|
||||
|
||||
header, #vendorStrip, #encyclopedia, #hero h1, #hero h5, #docs #hero h1, #docs #hero h5,
|
||||
@@ -108,11 +108,11 @@ $video-section-height: 550px
|
||||
|
||||
#home
|
||||
section, header, footer
|
||||
.main-section
|
||||
main
|
||||
max-width: 1000px
|
||||
|
||||
#oceanNodes
|
||||
.main-section
|
||||
main
|
||||
position: relative
|
||||
max-width: 830px
|
||||
|
||||
@@ -129,7 +129,7 @@ $video-section-height: 550px
|
||||
transform: translateY(-50%)
|
||||
|
||||
img
|
||||
width: 425px
|
||||
max-width: 425px
|
||||
|
||||
//.content
|
||||
// width: 50%
|
||||
@@ -172,7 +172,7 @@ $video-section-height: 550px
|
||||
background-image: url(../images/texture.png)
|
||||
background-color: $dark-grey
|
||||
|
||||
.main-section
|
||||
main
|
||||
padding: 20px 0
|
||||
|
||||
nav
|
||||
@@ -211,9 +211,9 @@ $video-section-height: 550px
|
||||
|
||||
.social a
|
||||
display: inline-block
|
||||
background-image: url(../images/social_sprite.svg)
|
||||
background-image: url(../images/social_sprite.png)
|
||||
background-repeat: no-repeat
|
||||
background-size: 350px
|
||||
background-size: auto
|
||||
width: 50px
|
||||
height: 50px
|
||||
border-radius: 5px
|
||||
@@ -264,12 +264,6 @@ $video-section-height: 550px
|
||||
&:hover
|
||||
background-position: -250px 100%
|
||||
|
||||
a.youtube
|
||||
background-position: -300px 0
|
||||
|
||||
&:hover
|
||||
background-position: -300px 100%
|
||||
|
||||
#community, .gridPage
|
||||
#hero
|
||||
text-align: left
|
||||
|
||||
@@ -26,7 +26,7 @@ section, header, #vendorStrip
|
||||
padding-left: $full-width-paddingX
|
||||
padding-right: $full-width-paddingX
|
||||
|
||||
.main-section
|
||||
main
|
||||
width: $main-width
|
||||
max-width: $main-max-width
|
||||
|
||||
@@ -59,7 +59,7 @@ header
|
||||
.nav-box + .nav-box
|
||||
margin-left: $nav-box-sibling-margin-left
|
||||
|
||||
.main-secton + .main-section
|
||||
main + main
|
||||
margin-top: $main-nav-main-sibling-margin-top
|
||||
|
||||
.left .button
|
||||
|
||||
@@ -116,7 +116,7 @@ $feature-box-div-width: 45%
|
||||
text-align: left
|
||||
margin-bottom: 18px
|
||||
|
||||
main, .main-section
|
||||
main
|
||||
position: relative
|
||||
clear: both
|
||||
display: table
|
||||
|
||||
@@ -66,30 +66,18 @@ time_format_blog = "Monday, January 02, 2006"
|
||||
description = "Production-Grade Container Orchestration"
|
||||
showedit = true
|
||||
|
||||
latest = "v1.17"
|
||||
latest = "v1.18"
|
||||
|
||||
fullversion = "v1.17.0"
|
||||
version = "v1.17"
|
||||
githubbranch = "master"
|
||||
docsbranch = "master"
|
||||
deprecated = false
|
||||
fullversion = "v1.14.10"
|
||||
version = "v1.14"
|
||||
githubbranch = "v1.14.10"
|
||||
docsbranch = "release-1.14"
|
||||
deprecated = true
|
||||
currentUrl = "https://kubernetes.io/docs/home/"
|
||||
nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/"
|
||||
githubWebsiteRepo = "github.com/kubernetes/website"
|
||||
githubWebsiteRaw = "raw.githubusercontent.com/kubernetes/website"
|
||||
|
||||
# param for displaying an announcement block on every page; see PR #16210
|
||||
announcement = false
|
||||
# announcement_message is only displayed when announcement = true; update with your specific message
|
||||
announcement_message = "The Kubernetes Documentation team would like your feedback! Please take a <a href='https://www.surveymonkey.com/r/8R237FN' target='_blank'>short survey</a> so we can improve the Kubernetes online documentation."
|
||||
|
||||
[[params.versions]]
|
||||
fullversion = "v1.17.0"
|
||||
version = "v1.17"
|
||||
githubbranch = "v1.17.0"
|
||||
docsbranch = "release-1.17"
|
||||
url = "https://kubernetes.io"
|
||||
|
||||
[params.pushAssets]
|
||||
css = [
|
||||
"callouts",
|
||||
@@ -102,33 +90,40 @@ js = [
|
||||
]
|
||||
|
||||
[[params.versions]]
|
||||
fullversion = "v1.16.3"
|
||||
fullversion = "v1.18.0"
|
||||
version = "v1.18"
|
||||
githubbranch = "v1.18.0"
|
||||
docsbranch = "release-1.18"
|
||||
url = "https://kubernetes.io"
|
||||
|
||||
[[params.versions]]
|
||||
fullversion = "v1.17.4"
|
||||
version = "v1.17"
|
||||
githubbranch = "v1.17.4"
|
||||
docsbranch = "release-1.17"
|
||||
url = "https://v1-17.docs.kubernetes.io"
|
||||
|
||||
[[params.versions]]
|
||||
fullversion = "v1.16.8"
|
||||
version = "v1.16"
|
||||
githubbranch = "v1.16.3"
|
||||
githubbranch = "v1.16.8"
|
||||
docsbranch = "release-1.16"
|
||||
url = "https://v1-16.docs.kubernetes.io"
|
||||
|
||||
[[params.versions]]
|
||||
fullversion = "v1.15.6"
|
||||
fullversion = "v1.15.11"
|
||||
version = "v1.15"
|
||||
githubbranch = "v1.15.6"
|
||||
githubbranch = "v1.15.11"
|
||||
docsbranch = "release-1.15"
|
||||
url = "https://v1-15.docs.kubernetes.io"
|
||||
|
||||
[[params.versions]]
|
||||
fullversion = "v1.14.9"
|
||||
fullversion = "v1.14.10"
|
||||
version = "v1.14"
|
||||
githubbranch = "v1.14.9"
|
||||
githubbranch = "v1.14.10"
|
||||
docsbranch = "release-1.14"
|
||||
url = "https://v1-14.docs.kubernetes.io"
|
||||
|
||||
[[params.versions]]
|
||||
fullversion = "v1.13.12"
|
||||
version = "v1.13"
|
||||
githubbranch = "v1.13.12"
|
||||
docsbranch = "release-1.13"
|
||||
url = "https://v1-13.docs.kubernetes.io"
|
||||
|
||||
# Language definitions.
|
||||
|
||||
[languages]
|
||||
@@ -141,7 +136,7 @@ weight = 1
|
||||
|
||||
[languages.zh]
|
||||
title = "Kubernetes"
|
||||
description = "生产级别的容器编排系统"
|
||||
description = "Production-Grade Container Orchestration"
|
||||
languageName = "中文 Chinese"
|
||||
weight = 2
|
||||
contentDir = "content/zh"
|
||||
@@ -149,10 +144,11 @@ contentDir = "content/zh"
|
||||
[languages.zh.params]
|
||||
time_format_blog = "2006.01.02"
|
||||
language_alternatives = ["en"]
|
||||
deprecated = false
|
||||
|
||||
[languages.ko]
|
||||
title = "Kubernetes"
|
||||
description = "운영 수준의 컨테이너 오케스트레이션"
|
||||
description = "Production-Grade Container Orchestration"
|
||||
languageName = "한국어 Korean"
|
||||
weight = 3
|
||||
contentDir = "content/ko"
|
||||
@@ -210,7 +206,7 @@ language_alternatives = ["en"]
|
||||
|
||||
[languages.de]
|
||||
title = "Kubernetes"
|
||||
description = "Produktionsreife Container-Orchestrierung"
|
||||
description = "Production-Grade Container Orchestration"
|
||||
languageName ="Deutsch"
|
||||
weight = 8
|
||||
contentDir = "content/de"
|
||||
@@ -259,30 +255,6 @@ language_alternatives = ["en"]
|
||||
[languages.hi]
|
||||
title = "Kubernetes"
|
||||
description = "Production-Grade Container Orchestration"
|
||||
languageName = "Hindi"
|
||||
languageName ="Hindi"
|
||||
weight = 11
|
||||
contentDir = "content/hi"
|
||||
|
||||
[languages.hi.params]
|
||||
time_format_blog = "01.02.2006"
|
||||
language_alternatives = ["en"]
|
||||
|
||||
[languages.vi]
|
||||
title = "Kubernetes"
|
||||
description = "Giải pháp điều phối container trong môi trường production"
|
||||
languageName = "Tiếng Việt"
|
||||
contentDir = "content/vi"
|
||||
weight = 12
|
||||
|
||||
[languages.ru]
|
||||
title = "Kubernetes"
|
||||
description = "Первоклассная оркестрация контейнеров"
|
||||
languageName = "Русский"
|
||||
weight = 12
|
||||
contentDir = "content/ru"
|
||||
|
||||
[languages.ru.params]
|
||||
time_format_blog = "02.01.2006"
|
||||
# A list of language codes to look for untranslated content, ordered from left to right.
|
||||
language_alternatives = ["en"]
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Produktionsreife Container-Orchestrierung"
|
||||
title: "Production-Grade Container Orchestration"
|
||||
abstract: "Automatisierte Bereitstellung, Skalierung und Verwaltung von Containern"
|
||||
cid: home
|
||||
---
|
||||
@@ -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-north-america-2019" button id="desktopKCButton">KubeCon vom 18-21. November 2019 in San Diego</a>
|
||||
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2019" button id="desktopKCButton">KubeCon vom 20-23. Mai 2019 in Barcelona</a>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<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>
|
||||
<a href="https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019" button id="desktopKCButton">KubeCon vom 24-26. Juni 2019 in Shanghai</a>
|
||||
</div>
|
||||
<div id="videoPlayer">
|
||||
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Fallstudien
|
||||
linkTitle: Fallstudien
|
||||
bigheader: Kubernetes Anwenderberichte
|
||||
bigheader: Kubernetes Anwenderberichte
|
||||
abstract: Eine Sammlung von Benutzern, die Kubernetes in Produktion verwenden.
|
||||
layout: basic
|
||||
class: gridPage
|
||||
|
||||
@@ -26,9 +26,9 @@ cid: community
|
||||
|
||||
<div class="content">
|
||||
<h3>Verhaltensregeln</h3>
|
||||
<p>Die Kubernetes-Community schätzt Respekt und Inklusivität und setzt einen <a href="code-of-conduct/">Verhaltenskodex</a>
|
||||
in allen Interaktionen durch. Wenn Sie einen Verstoß gegen den Verhaltenskodex bei einer Veranstaltung oder Sitzung,
|
||||
in Slack oder in einem anderen Kommunikationsmechanismus feststellen, wenden Sie sich
|
||||
<p>Die Kubernetes-Community schätzt Respekt und Inklusivität und setzt einen <a href="code-of-conduct/">Verhaltenskodex</a>
|
||||
in allen Interaktionen durch. Wenn Sie einen Verstoß gegen den Verhaltenskodex bei einer Veranstaltung oder Sitzung,
|
||||
in Slack oder in einem anderen Kommunikationsmechanismus feststellen, wenden Sie sich
|
||||
bitte an das <a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct">Kubernetes Code of Conduct Committee</a> <a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>. Ihre Anonymität wird geschützt.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
@@ -7,7 +7,7 @@ weight: 40
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Im Abschnitt Konzepte erfahren Sie mehr über die Bestandteile des Kubernetes-Systems und die Abstraktionen, die Kubernetes zur Verwaltung Ihres Clusters zur Verfügung stellt. Sie erhalten zudem ein tieferes Verständnis der Funktionsweise von Kubernetes.
|
||||
Im Abschnitt Konzepte erfahren Sie mehr über die Teile des Kubernetes-Systems und die Abstraktionen, die Kubernetes zur Darstellung Ihres Clusters verwendet, und Sie erhalten ein tieferes Verständnis der Funktionsweise von Kubernetes.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -15,10 +15,10 @@ Im Abschnitt Konzepte erfahren Sie mehr über die Bestandteile des Kubernetes-Sy
|
||||
|
||||
## Überblick
|
||||
|
||||
Um mit Kubernetes zu arbeiten, verwenden Sie *Kubernetes-API-Objekte*, um den *gewünschten Status Ihres Clusters* zu beschreiben:
|
||||
welche Anwendungen oder anderen Workloads Sie ausführen möchten, welche Containerimages sie verwenden, die Anzahl der Replikate, welche Netzwerk- und Festplattenressourcen Sie zur Verfügung stellen möchten, und vieles mehr. Sie legen den gewünschten Status fest, indem Sie Objekte mithilfe der Kubernetes-API erstellen. Dies geschieht normalerweise über die Befehlszeilenschnittstelle `kubectl`. Sie können die Kubernetes-API auch direkt verwenden, um mit dem Cluster zu interagieren und den gewünschten Status festzulegen oder zu ändern.
|
||||
Um mit Kubernetes zu arbeiten, verwenden Sie *Kubernetes-API-Objekte*, um den *gewünschten Status Ihres Clusters* zu beschreiben:
|
||||
welche Anwendungen oder anderen Workloads Sie ausführen möchten, welche Containerimages sie verwenden, die Anzahl der Replikate, welche Netzwerk- und Festplattenressourcen Sie zur Verfügung stellen möchten, und vieles mehr. Sie legen den gewünschten Status fest, indem Sie Objekte mithilfe der Kubernetes-API erstellen, normalerweise über die Befehlszeilenschnittstelle `kubectl`. Sie können die Kubernetes-API auch direkt verwenden, um mit dem Cluster zu interagieren und den gewünschten Status festzulegen oder zu ändern.
|
||||
|
||||
Sobald Sie den gewünschten Status eingestellt haben, wird das *Kubernetes Control Plane* dafür sorgen, dass der aktuelle Status des Clusters mit dem gewünschten Status übereinstimmt. Zu diesem Zweck führt Kubernetes verschiedene Aufgaben automatisch aus, z. B. das Starten oder Neustarten von Containern, Skalieren der Anzahl der Repliken einer bestimmten Anwendung und vieles mehr. Das Kubernetes Control Plane besteht aus einer Reihe von Prozessen, die in Ihrem Cluster ausgeführt werden:
|
||||
Sobald Sie den gewünschten Status eingestellt haben, wird das *Kubernetes Control Plane* dafür sorgen, dass der aktuelle Status des Clusters mit dem gewünschten Status übereinstimmt. Zu diesem Zweck führt Kubernetes verschiedene Aufgaben automatisch aus, z. B. Starten oder Neustarten von Containern, Skalieren der Anzahl der Repliken einer bestimmten Anwendung und vieles mehr. Das Kubernetes Control Plane besteht aus einer Reihe von Prozessen, die in Ihrem Cluster ausgeführt werden:
|
||||
|
||||
* Der **Kubernetes Master** bestehet aus drei Prozessen, die auf einem einzelnen Node in Ihrem Cluster ausgeführt werden, der als Master-Node bezeichnet wird. Diese Prozesse sind:[kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) und [kube-scheduler](/docs/admin/kube-scheduler/).
|
||||
* Jeder einzelne Node in Ihrem Cluster, welcher nicht der Master ist, führt zwei Prozesse aus:
|
||||
@@ -27,16 +27,16 @@ Sobald Sie den gewünschten Status eingestellt haben, wird das *Kubernetes Contr
|
||||
|
||||
## Kubernetes Objects
|
||||
|
||||
Kubernetes enthält eine Reihe von Abstraktionen, die den Status Ihres Systems darstellen: im Container eingesetzte Anwendungen und Workloads, die zugehörigen Netzwerk- und Festplattenressourcen sowie weitere Informationen zu den Aufgaben Ihres Clusters. Diese Abstraktionen werden durch Objekte in der Kubernetes-API dargestellt; Lesen Sie [Kubernetes Objects Überblick](/docs/concepts/abstractions/overview/) für weitere Details.
|
||||
Kubernetes enthält eine Reihe von Abstraktionen, die den Status Ihres Systems darstellen: implementierte containerisierte Anwendungen und Workloads, die zugehörigen Netzwerk- und Festplattenressourcen sowie weitere Informationen zu den Aufgaben Ihres Clusters. Diese Abstraktionen werden durch Objekte in der Kubernetes-API dargestellt; Lesen Sie [Kubernetes Objects Überblick](/docs/concepts/abstractions/overview/) für weitere Details.
|
||||
|
||||
Die Basisobjekte von Kubernetes umfassen:
|
||||
Die grundlegenden Objekte von Kubernetes umfassen:
|
||||
|
||||
* [Pod](/docs/concepts/workloads/pods/pod-overview/)
|
||||
* [Service](/docs/concepts/services-networking/service/)
|
||||
* [Volume](/docs/concepts/storage/volumes/)
|
||||
* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
|
||||
Darüber hinaus enthält Kubernetes Abstraktionen auf höherer Ebene, die als Controller bezeichnet werden. Controller bauen auf den Basisobjekten auf und bieten zusätzliche Funktionen und Komfortfunktionen. Sie beinhalten:
|
||||
Darüber hinaus enthält Kubernetes eine Reihe von Abstraktionen auf höherer Ebene, die als Controller bezeichnet werden. Controller bauen auf den Basisobjekten auf und bieten zusätzliche Funktionen und Komfortfunktionen. Sie beinhalten:
|
||||
|
||||
* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
@@ -46,19 +46,19 @@ Darüber hinaus enthält Kubernetes Abstraktionen auf höherer Ebene, die als Co
|
||||
|
||||
## Kubernetes Control Plane
|
||||
|
||||
Die verschiedenen Teile der Kubernetes-Steuerungsebene (Control Plane), wie der Kubernetes Master- und der Kubelet-Prozess, bestimmen, wie Kubernetes mit Ihrem Cluster kommuniziert. Das Control Plane verwaltet ein Inventar aller Kubernetes-Objekte im System und führt kontinuierlich Kontrollschleifen aus, um den Status dieser Objekte zu verwalten. Zu jeder Zeit reagieren die Kontrollschleifen des Control Plane auf Änderungen im Cluster und arbeiten daran, dass der tatsächliche Status aller Objekte im System mit dem von Ihnen definierten Status übereinstimmt.
|
||||
Die verschiedenen Teile der Kubernetes-Steuerungsebene (Control Plane), wie der Kubernetes Master- und der Kubelet-Prozess, bestimmen, wie Kubernetes mit Ihrem Cluster kommuniziert. Das Control Plane führt ein Inventar aller Kubernetes-Objekte im System und führt fortlaufende Steuerkreise aus, um den Status dieser Objekte zu verwalten. Zu jeder Zeit reagieren die Steuerkreise des Control Plane auf Änderungen im Cluster und arbeiten daran, dass der tatsächliche Status aller Objekte im System mit dem gewünschten Status, den Sie definiert haben, übereinstimmt.
|
||||
|
||||
Wenn Sie beispielsweise mit der Kubernetes-API ein Deployment-Objekt erstellen, geben Sie einen neuen gewünschten Status für das System an. Das Kubernetes Control Plane zeichnet die Objekterstellung auf und führt Ihre Anweisungen aus, indem es die erforderlichen Anwendungen startet und Sie für auf den Cluster-Nodes plant - Dadurch wird der tatsächliche Status des Clusters an den gewünschten Status angepasst.
|
||||
Wenn Sie beispielsweise mit der Kubernetes-API ein Deployment-Objekt erstellen, geben Sie einen neuen gewünschten Status für das System an. Das Kubernetes Control Plane zeichnet die Objekterstellung auf und führt Ihre Anweisungen aus, indem es die erforderlichen Anwendungen startet und sie für auf den Cluster-Nodes plant--Dadurch wird der tatsächliche Status des Clusters an den gewünschten Status angepasst.
|
||||
|
||||
### Kubernetes Master
|
||||
|
||||
Der Kubernetes-Master ist für Erhalt des gewünschten Status Ihres Clusters verantwortlich. Wenn Sie mit Kubernetes interagieren, beispielsweise mit dem Kommanduzeilen-Tool `kubectl`, kommunizieren Sie mit dem Kubernetes-Master Ihres Clusters.
|
||||
Der Kubernetes-Master ist für die Aufrechterhaltung des gewünschten Status für Ihren Cluster verantwortlich. Wenn Sie mit Kubernetes interagieren, beispielsweise mit dem Kommanduzeilen-Tool `kubectl`, kommunizieren Sie mit dem Kubernetes-Master Ihres Clusters.
|
||||
|
||||
> Der Begriff "Master" bezeichnet dabei eine Reihe von Prozessen, die den Clusterstatus verwalten. Normalerweise werden diese Prozesse alle auf einem einzigen Node im Cluster ausgeführt. Dieser Node wird auch als Master bezeichnet. Der Master kann repliziert werden, um die Verfügbarkeit und Redundanz zu erhöhen.
|
||||
> Der "Master" bezieht sich auf eine Reihe von Prozessen, die den Clusterstatus verwalten. Normalerweise werden diese Prozesse alle auf einem einzigen Node im Cluster ausgeführt. Dieser Node wird auch als Master bezeichnet. Der Master kann repliziert werden um Verfügbarkeit und Redundanz zu erhöhen.
|
||||
|
||||
### Kubernetes Nodes
|
||||
|
||||
Die Nodes in einem Cluster sind die Maschinen (VMs, physische Server usw.), auf denen Ihre Anwendungen und Cloud-Workflows ausgeführt werden. Der Kubernetes-Master steuert jeden Node; Sie werden selten direkt mit Nodes interagieren.
|
||||
Die Nodes in einem Cluster sind die Maschinen (VMs, physische Server usw.), auf denen Ihre Anwendungen und Cloud-Workflows ausgeführt werden. Der Kubernetes-Master steuert jeden Master. Sie werden selten direkt mit Nodes interagieren.
|
||||
|
||||
#### Objekt Metadata
|
||||
|
||||
|
||||
@@ -1,238 +0,0 @@
|
||||
---
|
||||
title: Zugrunde liegende Konzepte des Cloud Controller Manager
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
Das Konzept des Cloud Controller Managers (CCM) (nicht zu verwechseln mit der Binärdatei) wurde ursprünglich entwickelt, um Cloud-spezifischen Anbieter Code und den Kubernetes Kern unabhängig voneinander entwickeln zu können. Der Cloud Controller Manager läuft zusammen mit anderen Master Komponenten wie dem Kubernetes Controller Manager, dem API-Server und dem Scheduler auf dem Host. Es kann auch als Kubernetes Addon gestartet werden, in diesem Fall läuft er auf Kubernetes.
|
||||
|
||||
Das Design des Cloud Controller Managers basiert auf einem Plugin Mechanismus, der es neuen Cloud Anbietern ermöglicht, sich mit Kubernetes einfach über Plugins zu integrieren. Es gibt Pläne für die Einbindung neuer Cloud Anbieter auf Kubernetes und für die Migration von Cloud Anbietern vom alten Modell auf das neue CCM-Modell.
|
||||
|
||||
Dieses Dokument beschreibt die Konzepte hinter dem Cloud Controller Manager und gibt Details zu den damit verbundenen Funktionen.
|
||||
|
||||
Die Architektur eines Kubernetes Clusters ohne den Cloud Controller Manager sieht wie folgt aus:
|
||||
|
||||

|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Design
|
||||
|
||||
Im vorhergehenden Diagramm sind Kubernetes und der Cloud-Provider über mehrere verschiedene Komponenten integriert:
|
||||
|
||||
* Kubelet
|
||||
* Kubernetes Controller Manager
|
||||
* Kubernetes API Server
|
||||
|
||||
CCM konsolidiert die gesamte Abhängigkeit der Cloud Logik von den drei vorhergehenden Komponenten zu einem einzigen Integrationspunkt mit der Cloud. So sieht die neue Architektur mit dem CCM aus:
|
||||
|
||||

|
||||
|
||||
## Komponenten des CCM
|
||||
|
||||
Der CCM löst einen Teil der Funktionalität des Kubernetes Controller Managers (KCM) ab und führt ihn als separaten Prozess aus. Konkret trennt es die Cloud abhängigen Controller im KCM. Der KCM verfügt über die folgenden Cloud abhängigen Steuerungsschleifen:
|
||||
|
||||
* Node Controller
|
||||
* Volume Controller
|
||||
* Route Controller
|
||||
* Service Controller
|
||||
|
||||
In der Version 1.9 führt der CCM die folgenden Controller aus der vorhergehenden Liste aus:
|
||||
|
||||
* Node Controller
|
||||
* Route Controller
|
||||
* Service Controller
|
||||
|
||||
{{< note >}}
|
||||
Der Volume Controller wurde bewusst nicht als Teil des CCM gewählt. Aufgrund der Komplexität und der bestehenden Bemühungen, herstellerspezifische Volume Logik zu abstrahieren, wurde entschieden, dass der Volume Controller nicht zum CCM verschoben wird.
|
||||
{{< /note >}}
|
||||
|
||||
Der ursprüngliche Plan, Volumes mit CCM zu integrieren, sah die Verwendung von Flex-Volumes vor welche austauschbare Volumes unterstützt. Allerdings ist eine konkurrierende Initiative namens CSI geplant, um Flex zu ersetzen.
|
||||
|
||||
In Anbetracht dieser Dynamik haben wir uns entschieden, eine Zwischenstopp durchzuführen um die Unterschiede zu beobachten , bis das CSI bereit ist.
|
||||
|
||||
## Funktionen des CCM
|
||||
|
||||
Der CCM erbt seine Funktionen von Komponenten des Kubernetes, die von einem Cloud Provider abhängig sind. Dieser Abschnitt ist auf der Grundlage dieser Komponenten strukturiert.
|
||||
|
||||
### 1. Kubernetes Controller Manager
|
||||
|
||||
Die meisten Funktionen des CCM stammen aus dem KCM. Wie im vorherigen Abschnitt erwähnt, führt das CCM die folgenden Steuerschleifen durch:
|
||||
|
||||
* Node Controller
|
||||
* Route Controller
|
||||
* Service Controller
|
||||
|
||||
#### Node Controller
|
||||
|
||||
Der Node Controller ist für die Initialisierung eines Knotens verantwortlich, indem er Informationen über die im Cluster laufenden Knoten vom Cloud Provider erhält. Der Node Controller führt die folgenden Funktionen aus:
|
||||
|
||||
1. Initialisierung eines Knoten mit Cloud-spezifischen Zonen-/Regionen Labels.
|
||||
2. Initialisieren von Knoten mit Cloud-spezifischen Instanzdetails, z.B. Typ und Größe.
|
||||
3. Ermitteln der Netzwerkadressen und des Hostnamen des Knotens.
|
||||
4. Falls ein Knoten nicht mehr reagiert, überprüft der Controller die Cloud, um festzustellen, ob der Knoten aus der Cloud gelöscht wurde.
|
||||
Wenn der Knoten aus der Cloud gelöscht wurde, löscht der Controller das Kubernetes Node Objekt.
|
||||
|
||||
#### Route Controller
|
||||
|
||||
Der Route Controller ist dafür verantwortlich, Routen in der Cloud so zu konfigurieren, dass Container auf verschiedenen Knoten im Kubernetes Cluster miteinander kommunizieren können. Der Route Controller ist nur auf einem Google Compute Engine Cluster anwendbar.
|
||||
|
||||
#### Service Controller
|
||||
|
||||
Der Service Controller ist verantwortlich für das Abhören von Ereignissen zum Erstellen, Aktualisieren und Löschen von Diensten. Basierend auf dem aktuellen Stand der Services in Kubernetes konfiguriert es Cloud Load Balancer (wie ELB, Google LB oder Oracle Cloud Infrastructure LB), um den Zustand der Services in Kubernetes abzubilden. Darüber hinaus wird sichergestellt, dass die Service Backends für Cloud Loadbalancer auf dem neuesten Stand sind.
|
||||
|
||||
### 2. Kubelet
|
||||
|
||||
Der Node Controller enthält die Cloud-abhängige Funktionalität des Kubelets. Vor der Einführung des CCM war das Kubelet für die Initialisierung eines Knotens mit cloudspezifischen Details wie IP-Adressen, Regions-/Zonenbezeichnungen und Instanztypinformationen verantwortlich. Mit der Einführung des CCM wurde diese Initialisierungsoperation aus dem Kubelet in das CCM verschoben.
|
||||
|
||||
In diesem neuen Modell initialisiert das Kubelet einen Knoten ohne cloudspezifische Informationen. Es fügt jedoch dem neu angelegten Knoten einen Taint hinzu, der den Knoten nicht verplanbar macht, bis der CCM den Knoten mit cloudspezifischen Informationen initialisiert. Dann wird der Taint entfernt.
|
||||
|
||||
## Plugin Mechanismus
|
||||
|
||||
Der Cloud Controller Manager verwendet die Go Schnittstellen, um Implementierungen aus jeder Cloud einzubinden. Konkret verwendet dieser das CloudProvider Interface, das [hier](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62) definiert ist.
|
||||
|
||||
Die Implementierung der vier oben genannten geteiltent Controllern und einigen Scaffolding sowie die gemeinsame CloudProvider Schnittstelle bleiben im Kubernetes Kern. Cloud Provider spezifische Implementierungen werden außerhalb des Kerns aufgebaut und implementieren im Kern definierte Schnittstellen.
|
||||
|
||||
Weitere Informationen zur Entwicklung von Plugins findest du im Bereich [Entwickeln von Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
|
||||
|
||||
## Autorisierung
|
||||
|
||||
Dieser Abschnitt beschreibt den Zugriff, den der CCM für die Ausführung seiner Operationen auf verschiedene API Objekte benötigt.
|
||||
|
||||
### Node Controller
|
||||
|
||||
Der Node Controller funktioniert nur mit Node Objekten. Es benötigt vollen Zugang zu get, list, create, update, patch, watch, und delete Node Objekten.
|
||||
|
||||
v1/Node:
|
||||
|
||||
- Get
|
||||
- List
|
||||
- Create
|
||||
- Update
|
||||
- Patch
|
||||
- Watch
|
||||
- Delete
|
||||
|
||||
### Route Controller
|
||||
|
||||
Der Route Controller horcht auf die Erstellung von Node Objekten und konfiguriert die Routen entsprechend. Es erfordert get Zugriff auf die Node Objekte.
|
||||
|
||||
v1/Node:
|
||||
|
||||
- Get
|
||||
|
||||
### Service Controller
|
||||
|
||||
Der Service Controller hört auf die Service Objekt Events create, update und delete und konfiguriert dann die Endpunkte für diese Services entsprechend.
|
||||
|
||||
Um auf Services zuzugreifen, benötigt man list und watch Berechtigung. Um die Services zu aktualisieren, sind patch und update Zugriffsrechte erforderlich.
|
||||
|
||||
Um die Endpunkte für die Dienste einzurichten, benötigt der Controller Zugriff auf create, list, get, watch und update.
|
||||
|
||||
v1/Service:
|
||||
|
||||
- List
|
||||
- Get
|
||||
- Watch
|
||||
- Patch
|
||||
- Update
|
||||
|
||||
### Sonstiges
|
||||
|
||||
Die Implementierung des Kerns des CCM erfordert den Zugriff auf die Erstellung von Ereignissen und zur Gewährleistung eines sicheren Betriebs den Zugriff auf die Erstellung von ServiceAccounts.
|
||||
|
||||
v1/Event:
|
||||
|
||||
- Create
|
||||
- Patch
|
||||
- Update
|
||||
|
||||
v1/ServiceAccount:
|
||||
|
||||
- Create
|
||||
|
||||
Die RBAC ClusterRole für CCM sieht wie folgt aus:
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: cloud-controller-manager
|
||||
rules:
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- events
|
||||
verbs:
|
||||
- create
|
||||
- patch
|
||||
- update
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- nodes
|
||||
verbs:
|
||||
- '*'
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- nodes/status
|
||||
verbs:
|
||||
- patch
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- services
|
||||
verbs:
|
||||
- list
|
||||
- patch
|
||||
- update
|
||||
- watch
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- serviceaccounts
|
||||
verbs:
|
||||
- create
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- persistentvolumes
|
||||
verbs:
|
||||
- get
|
||||
- list
|
||||
- update
|
||||
- watch
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- endpoints
|
||||
verbs:
|
||||
- create
|
||||
- get
|
||||
- list
|
||||
- watch
|
||||
- update
|
||||
```
|
||||
|
||||
## Anbieter Implementierung
|
||||
|
||||
Die folgenden Cloud Anbieter haben CCMs implementiert:
|
||||
|
||||
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
|
||||
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
|
||||
* [AWS](https://github.com/kubernetes/cloud-provider-aws)
|
||||
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
|
||||
* [Linode](https://github.com/linode/linode-cloud-controller-manager)
|
||||
|
||||
## Cluster Administration
|
||||
|
||||
Eine vollständige Anleitung zur Konfiguration und zum Betrieb des CCM findest du [hier](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager).
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -6,7 +6,7 @@ weight: 20
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Dieses Dokument katalogisiert die Kommunikationspfade zwischen dem Master (eigentlich dem Apiserver) und des Kubernetes-Clusters.
|
||||
Dieses Dokument katalogisiert die Kommunikationspfade zwischen dem Master (eigentlich dem Apiserver) und des Kubernetes-Clusters.
|
||||
Die Absicht besteht darin, Benutzern die Möglichkeit zu geben, ihre Installation so anzupassen, dass die Netzwerkkonfiguration so abgesichert wird, dass der Cluster in einem nicht vertrauenswürdigen Netzwerk (oder mit vollständig öffentlichen IP-Adressen eines Cloud-Providers) ausgeführt werden kann.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -20,11 +20,11 @@ Alle Kommunikationspfade vom Cluster zum Master enden beim Apiserver (keine der
|
||||
In einem typischen Setup ist der Apiserver so konfiguriert, dass er Remote-Verbindungen an einem sicheren HTTPS-Port (443) mit einer oder mehreren Formen der [Clientauthentifizierung](/docs/reference/access-authn-authz/authentication/) überwacht.
|
||||
Eine oder mehrere Formene von [Autorisierung](/docs/reference/access-authn-authz/authorization/) sollte aktiviert sein, insbesondere wenn [anonyme Anfragen](/docs/reference/access-authn-authz/authentication/#anonymous-requests) oder [Service Account Tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) aktiviert sind.
|
||||
|
||||
Nodes sollten mit dem öffentlichen Stammzertifikat für den Cluster konfiguriert werden, sodass sie eine sichere Verbindung zum Apiserver mit gültigen Client-Anmeldeinformationen herstellen können.
|
||||
Nodes sollten mit dem öffentlichen Stammzertifikat für den Cluster konfigurirert werden, sodass sie eine sichere Verbindung zum Apiserver mit gültigen Client-Anmeldeinformationen herstellen können.
|
||||
Beispielsweise bei einer gewöhnlichen GKE-Konfiguration enstprechen die dem kubelet zur Verfügung gestellten Client-Anmeldeinformationen eines Client-Zertifikats.
|
||||
Lesen Sie über [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) zur automatisierten Bereitstellung von kubelet-Client-Zertifikaten.
|
||||
|
||||
Pods, die eine Verbindung zum Apiserver herstellen möchten, können dies auf sichere Weise tun, indem sie ein Dienstkonto verwenden, sodass Kubernetes das öffentliche Stammzertifikat und ein gültiges Trägertoken automatisch in den Pod einfügt, wenn er instanziiert wird.
|
||||
Pods, die eine Verbindung zum Apiserver herstellen möchten, können dies auf sichere Weise tun, indem sie ein Dienstkonto verwenden, sodass Kubernetes das öffentliche Stammzertifikat und ein gültiges Trägertoken automatisch in den Pod einfügt, wenn er instanziert wird.
|
||||
Der `kubernetes`-Dienst (in allen Namespaces) ist mit einer virtuellen IP-Adresse konfiguriert, die (über den Kube-Proxy) an den HTTPS-Endpunkt auf dem Apiserver umgeleitet wird.
|
||||
|
||||
Die Master-Komponenten kommunizieren auch über den sicheren Port mit dem Cluster-Apiserver.
|
||||
@@ -34,26 +34,26 @@ Der Standardbetriebsmodus für Verbindungen vom Cluster (Knoten und Pods, die au
|
||||
## Master zum Cluster
|
||||
|
||||
Es gibt zwei primäre Kommunikationspfade vom Master (Apiserver) zum Cluster.
|
||||
Der Erste ist vom Apiserver hin zum Kubelet-Prozess, der auf jedem Node im Cluster ausgeführt wird.
|
||||
Der Zweite ist vom Apiserver zu einem beliebigen Node, Pod oder Dienst über die Proxy-Funktionalität des Apiservers.
|
||||
Der erste ist vom Apiserver bis zum Kubelet-Prozess, der auf jedem Node im Cluster ausgeführt wird.
|
||||
Der zweite ist vom Apiserver zu einem beliebigen Node, Pod oder Dienst über die Proxy-Funktionalität des Apiservers.
|
||||
|
||||
### Apiserver zum kubelet
|
||||
|
||||
Die Verbindungen vom Apiserver zum Kubelet werden verwendet für:
|
||||
|
||||
* Das Abrufen von Protokollen für Pods.
|
||||
* Das Verbinden (durch kubectl) mit laufenden Pods.
|
||||
* Die Bereitstellung der Portweiterleitungsfunktion des kubelet.
|
||||
* Abrufen von Protokollen für Pods.
|
||||
* Verbinden (durch kubectl) mit laufenden Pods.
|
||||
* Bereitstellung der Portweiterleitungsfunktion des kubelet.
|
||||
|
||||
Diese Verbindungen enden am HTTPS-Endpunkt des kubelet.
|
||||
Standardmäßig überprüft der Apiserver das Serverzertifikat des Kubelets nicht, was die Verbindung angreifbar für Man-in-the-Middle-Angriffe macht. Die Kommunikation ist daher **unsicher**, wenn die Verbindungen über nicht vertrauenswürdige und/oder öffentliche Netzwerke laufen.
|
||||
Standardmäßig überprüft der Apiserver das Serverzertifikat des Kubelet nicht, was die Verbindung von angreifbar für Man-in-the-Middle-Angriffe macht, und ist es ist daher **unsicher** wenn die Verbindungen über nicht vertrauenswürdige und/oder öffentliche Netzwerke laufen.
|
||||
|
||||
Um diese Verbindung zu überprüfen, verwenden Sie das Flag `--kubelet-certificate-authority`, um dem Apiserver ein Stammzertifikatbündel bereitzustellen, das zur Überprüfung des Server-Zertifikats des kubelets verwendet wird.
|
||||
Um diese Verbindung zu überprüfen, verwenden Sie das Flag `--kubelet-certificate-authority`, um dem Apiserver ein Stammzertifikatbündel bereitzustellen, das zur Überprüfung des Server-Zertifikats des kubelet verwendet wird.
|
||||
|
||||
Wenn dies nicht möglich ist, verwenden Sie [SSH tunneling](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)
|
||||
zwischen dem Apiserver und dem kubelet, falls es erforderlich ist eine Verbindung über ein nicht vertrauenswürdiges oder öffentliches Netz zu vermeiden.
|
||||
zwischen dem Apiserver und kubelet, falls erforderlich, um eine Verbindung über ein nicht vertrauenswürdiges oder öffentliches Netz zu vermeiden.
|
||||
|
||||
Außerdem sollte [Kubelet Authentifizierung und/oder Autorisierung](/docs/admin/kubelet-authentication-authorization/) aktiviert sein, um die kubelet-API abzusichern.
|
||||
Ausserdem sollte, [Kubelet Authentifizierung und/oder Autorisierung](/docs/admin/kubelet-authentication-authorization/) sollte aktiviert sein, um die kubelet-API zu sichern.
|
||||
|
||||
### Apiserver zu Nodes, Pods und Services
|
||||
|
||||
@@ -63,10 +63,10 @@ Diese Verbindungen **sind derzeit nicht sicher** innerhalb von nicht vertrauensw
|
||||
|
||||
### SSH Tunnels
|
||||
|
||||
Kubernetes unterstützt SSH-Tunnel zum Schutz der Master -> Cluster Kommunikationspfade.
|
||||
In dieser Konfiguration initiiert der Apiserver einen SSH-Tunnel zu jedem Node im Cluster (Verbindung mit dem SSH-Server, der mit Port 22 läuft), und leitet den gesamten Datenverkehr für ein kubelet, einen Node, einen Pod oder einen Dienst durch den Tunnel.
|
||||
Kubernetes unterstützt SSH-Tunnel zum Schutz der Kommunikationspfade von Master -> Cluster.
|
||||
In dieser Konfiguration initiiert der Apiserver einen SSH-Tunnel zu jedem Nodem im Cluster (Verbindung mit dem SSH-Server, der Port 22 läuft), und leitet den gesamten Datenverkehr für ein kubelet, einen Node, einen Pod oder einen Dienst durch den Tunnel.
|
||||
Dieser Tunnel stellt sicher, dass der Datenverkehr nicht außerhalb des Netzwerks sichtbar ist, in dem die Knoten ausgeführt werden.
|
||||
|
||||
SSH-Tunnel werden zur Zeit nicht unterstützt. Sie sollten also nicht verwendet werden, sei denn, man weiß, was man tut. Ein Ersatz für diesen Kommunikationskanal wird entwickelt.
|
||||
SSH-Tunnel sind derzeit nicht mehr unterstützt. Sie sollten sie also nicht verwenden, es sei denn, Sie wissen, was Sie tun. Ein Ersatz für diesen Kommunikationskanal wird entwickelt.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -8,9 +8,9 @@ weight: 10
|
||||
|
||||
Ein Knoten (Node in Englisch) ist eine Arbeitsmaschine in Kubernetes, früher als `minion` bekannt. Ein Node
|
||||
kann je nach Cluster eine VM oder eine physische Maschine sein. Jeder Node enthält
|
||||
die für den Betrieb von [Pods](/docs/concepts/workloads/pods/pod/) notwendigen Dienste
|
||||
und wird von den Master-Komponenten verwaltet.
|
||||
Die Dienste auf einem Node umfassen die [Container Runtime](/docs/concepts/overview/components/#node-components), das Kubelet und den Kube-Proxy.
|
||||
die für den Betrieb von [Pods](/docs/concepts/workloads/pods/pod/) notwendigen Dienste
|
||||
und wird von den Master-Komponenten verwaltet.
|
||||
Die Dienste auf einem Node umfassen die [Container Runtime](/docs/concepts/overview/components/#node-components), das Kubelet und den Kube-Proxy.
|
||||
Weitere Informationen finden Sie im Abschnitt Kubernetes Node in der Architekturdesign-Dokumentation.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -64,13 +64,13 @@ Der Zustand eines Nodes wird als JSON-Objekt dargestellt. Die folgende Antwort b
|
||||
|
||||
Wenn der Status der `Ready`-Bedingung `Unknown` oder `False` länger als der `pod-eviction-timeout` bleibt, wird ein Parameter an den [kube-controller-manager](/docs/admin/kube-controller-manager/) übergeben und alle Pods auf dem Node werden vom Node Controller gelöscht.
|
||||
|
||||
Die voreingestellte Zeit vor der Entfernung beträgt **fünf Minuten**.
|
||||
In einigen Fällen, in denen der Node nicht erreichbar ist, kann der Apiserver nicht mit dem Kubelet auf dem Node kommunizieren.
|
||||
Die voreingestellte Zeit vor der Entfernung beträgt **fünf Minuten**.
|
||||
In einigen Fällen, in denen der Node nicht erreichbar ist, kann der Apiserver nicht mit dem Kubelet auf dem Node kommunizieren.
|
||||
Die Entscheidung, die Pods zu löschen, kann dem Kublet erst mitgeteilt werden, wenn die Kommunikation mit dem Apiserver wiederhergestellt ist.
|
||||
In der Zwischenzeit können Pods, deren Löschen geplant ist, weiterhin auf dem unzugänglichen Node laufen.
|
||||
|
||||
|
||||
In Versionen von Kubernetes vor 1.5 würde der Node Controller das Löschen dieser unerreichbaren Pods vom Apiserver [erzwingen](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods). In Version 1.5 und höher erzwingt der Node Controller jedoch keine Pod Löschung, bis bestätigt wird, dass sie nicht mehr im Cluster ausgeführt werden. Pods die auf einem unzugänglichen Node laufen sind eventuell in einem einem `Terminating` oder `Unkown` Status. In Fällen, in denen Kubernetes nicht aus der zugrunde liegenden Infrastruktur schließen kann, ob ein Node einen Cluster dauerhaft verlassen hat, muss der Clusteradministrator den Node möglicherweise manuell löschen.
|
||||
In Versionen von Kubernetes vor 1.5 würde der Node Controller das Löschen dieser unerreichbaren Pods vom Apiserver [erzwingen](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods). In Version 1.5 und höher erzwingt der Node Controller jedoch keine Pod Löschung, bis bestätigt wird, dass sie nicht mehr im Cluster ausgeführt werden. Pods die auf einem unzugänglichen Node laufen sind eventuell in einem einem `Terminating` oder `Unkown` Status. In Fällen, in denen Kubernetes nicht aus der zugrunde liegenden Infrastruktur schließen kann, ob ein Node einen Cluster dauerhaft verlassen hat, muss der Clusteradministrator den Node möglicherweise manuell löschen.
|
||||
Das Löschen des Kubernetes-Nodeobjekts bewirkt, dass alle auf dem Node ausgeführten Pod-Objekte gelöscht und deren Namen freigegeben werden.
|
||||
|
||||
In Version 1.12 wurde die Funktion `TaintNodesByCondition` als Beta-Version eingeführt, die es dem Node-Lebenszyklus-Controller ermöglicht, automatisch [Markierungen](/docs/concepts/configuration/taint-and-toleration/) (*taints* in Englisch) zu erstellen, die Bedingungen darstellen.
|
||||
@@ -79,13 +79,13 @@ Ebenso ignoriert der Scheduler die Bedingungen, wenn er einen Node berücksichti
|
||||
|
||||
Anwender können jetzt zwischen dem alten Scheduling-Modell und einem neuen, flexibleren Scheduling-Modell wählen.
|
||||
|
||||
Ein Pod, der keine Toleranzen aufweist, wird gemäß dem alten Modell geplant.
|
||||
Ein Pod, der keine Toleranzen aufweist, wird gemäß dem alten Modell geplant.
|
||||
Aber ein Pod, die die Taints eines bestimmten Node toleriert, kann auf diesem Node geplant werden.
|
||||
|
||||
{{< caution >}}
|
||||
Wenn Sie diese Funktion aktivieren, entsteht eine kleine Verzögerung zwischen der Zeit,
|
||||
in der eine Bedingung beobachtet wird, und der Zeit, in der ein Taint entsteht.
|
||||
Diese Verzögerung ist in der Regel kürzer als eine Sekunde, aber sie kann die Anzahl
|
||||
Wenn Sie diese Funktion aktivieren, entsteht eine kleine Verzögerung zwischen der Zeit,
|
||||
in der eine Bedingung beobachtet wird, und der Zeit, in der ein Taint entsteht.
|
||||
Diese Verzögerung ist in der Regel kürzer als eine Sekunde, aber sie kann die Anzahl
|
||||
der Pods erhöhen, die erfolgreich geplant, aber vom Kubelet abgelehnt werden.
|
||||
{{< /caution >}}
|
||||
|
||||
@@ -104,7 +104,7 @@ Die Informationen werden von Kubelet vom Node gesammelt.
|
||||
|
||||
Im Gegensatz zu [Pods](/docs/concepts/workloads/pods/pod/) und [Services](/docs/concepts/services-networking/service/),
|
||||
ein Node wird nicht von Kubernetes erstellt: Er wird extern von Cloud-Anbietern wie Google Compute Engine erstellt oder ist in Ihrem Pool physischer oder virtueller Maschinen vorhanden.
|
||||
Wenn Kubernetes also einen Node erstellt, wird ein Objekt erstellt, das den Node darstellt.
|
||||
Wenn Kubernetes also einen Node erstellt, wird ein Objekt erstellt, das den Node darstellt.
|
||||
Nach der Erstellung überprüft Kubernetes, ob der Node gültig ist oder nicht.
|
||||
|
||||
Wenn Sie beispielsweise versuchen, einen Node aus folgendem Inhalt zu erstellen:
|
||||
@@ -123,7 +123,7 @@ Wenn Sie beispielsweise versuchen, einen Node aus folgendem Inhalt zu erstellen:
|
||||
```
|
||||
|
||||
|
||||
Kubernetes erstellt intern ein Node-Oject (die Darstellung) und validiert den Node durch Zustandsprüfung basierend auf dem Feld `metadata.name`.
|
||||
Kubernetes erstellt intern ein Node-Oject (die Darstellung) und validiert den Node durch Zustandsprüfung basierend auf dem Feld `metadata.name`.
|
||||
Wenn der Node gültig ist, d.h. wenn alle notwendigen Dienste ausgeführt werden, ist er berechtigt, einen Pod auszuführen.
|
||||
Andernfalls wird er für alle Clusteraktivitäten ignoriert, bis er gültig wird.
|
||||
|
||||
@@ -140,45 +140,45 @@ Aktuell gibt es drei Komponenten, die mit dem Kubernetes Node-Interface interagi
|
||||
|
||||
Der Node Controller ist eine Kubernetes-Master-Komponente, die verschiedene Aspekte von Nodes verwaltet.
|
||||
|
||||
Der Node Controller hat mehrere Rollen im Leben eines Nodes.
|
||||
Der Node Controller hat mehrere Rollen im Leben eines Nodes.
|
||||
Der erste ist die Zuordnung eines CIDR-Blocks zu dem Node, wenn er registriert ist (sofern die CIDR-Zuweisung aktiviert ist).
|
||||
|
||||
Die zweite ist, die interne Node-Liste des Node Controllers mit der Liste der verfügbaren Computer des Cloud-Anbieters auf dem neuesten Stand zu halten.
|
||||
Wenn ein Node in einer Cloud-Umgebung ausgeführt wird und sich in einem schlechten Zustand befindet, fragt der Node Controller den Cloud-Anbieter, ob die virtuelle Maschine für diesen Node noch verfügbar ist. Wenn nicht, löscht der Node Controller den Node aus seiner Node-Liste.
|
||||
|
||||
Der dritte ist die Überwachung des Zustands der Nodes. Der Node Controller ist dafür verantwortlich,
|
||||
die NodeReady-Bedingung von NodeStatus auf ConditionUnknown zu aktualisieren, wenn ein wenn ein Node unerreichbar wird (der Node Controller empfängt aus irgendeinem Grund keine Herzschläge mehr, z.B. weil der Node heruntergefahren ist) und später alle Pods aus dem Node zu entfernen (und diese ordnungsgemäss zu beenden), wenn der Node weiterhin unzugänglich ist. (Die Standard-Timeouts sind 40s, um ConditionUnknown zu melden und 5 Minuten, um mit der Evakuierung der Pods zu beginnen).
|
||||
die NodeReady-Bedingung von NodeStatus auf ConditionUnknown zu aktualisieren, wenn ein wenn ein Node unerreichbar wird (der Node Controller empfängt aus irgendeinem Grund keine Herzschläge mehr, z.B. weil der Node heruntergefahren ist) und später alle Pods aus dem Node zu entfernen (und diese ordnungsgemäss zu beenden), wenn der Node weiterhin unzugänglich ist. (Die Standard-Timeouts sind 40s, um ConditionUnknown zu melden und 5 Minuten, um mit der Evakuierung der Pods zu beginnen).
|
||||
Der Node Controller überprüft den Zustand jedes Nodes alle `--node-monitor-period` Sekunden.
|
||||
|
||||
|
||||
In Versionen von Kubernetes vor 1.13 ist NodeStatus der Herzschlag des Nodes.
|
||||
Ab Kubernetes 1.13 wird das Node-Lease-Feature als Alpha-Feature eingeführt (Feature-Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)).
|
||||
Ab Kubernetes 1.13 wird das Node-Lease-Feature als Alpha-Feature eingeführt (Feature-Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)).
|
||||
|
||||
Wenn die Node Lease Funktion aktiviert ist, hat jeder Node ein zugeordnetes `Lease`-Objekt im `kube-node-lease`-Namespace, das vom Node regelmäßig erneuert wird.
|
||||
Sowohl NodeStatus als auch Node Lease werden als Herzschläge vom Node aus behandelt.
|
||||
Node Leases werden häufig erneuert, während NodeStatus nur dann vom Node zu Master gemeldet wird, wenn sich etwas ändert oder genügend Zeit vergangen ist (Standard ist 1 Minute, was länger ist als der Standard-Timeout von 40 Sekunden für unerreichbare Nodes).
|
||||
Wenn die Node Lease Funktion aktiviert ist, hat jeder Node ein zugeordnetes `Lease`-Objekt im `kube-node-lease`-Namespace, das vom Node regelmäßig erneuert wird.
|
||||
Sowohl NodeStatus als auch Node Lease werden als Herzschläge vom Node aus behandelt.
|
||||
Node Leases werden häufig erneuert, während NodeStatus nur dann vom Node zu Master gemeldet wird, wenn sich etwas ändert oder genügend Zeit vergangen ist (Standard ist 1 Minute, was länger ist als der Standard-Timeout von 40 Sekunden für unerreichbare Nodes).
|
||||
Da Node Leases viel lastärmer sind als NodeStatus, macht diese Funktion den Node Herzschlag sowohl in Bezug auf Skalierbarkeit als auch auf die Leistung deutlich effizienter.
|
||||
|
||||
In Kubernetes 1.4 haben wir die Logik der Node-Steuerung aktualisiert, um Fälle besser zu handhaben, in denen eine große Anzahl von Nodes Probleme hat, den Master zu erreichen (z.B. weil der Master Netzwerkprobleme hat).
|
||||
In Kubernetes 1.4 haben wir die Logik der Node-Steuerung aktualisiert, um Fälle besser zu handhaben, in denen eine große Anzahl von Nodes Probleme hat, den Master zu erreichen (z.B. weil der Master Netzwerkprobleme hat).
|
||||
Ab 1.4 betrachtet der Node-Controller den Zustand aller Nodes im Cluster, wenn er eine Entscheidung über die Enterfung eines Pods trifft.
|
||||
|
||||
In den meisten Fällen begrenzt der Node-Controller die Entfernungsrate auf `--node-eviction-rate` (Standard 0,1) pro Sekunde, was bedeutet, dass er die Pods nicht von mehr als einem Node pro 10 Sekunden entfernt.
|
||||
|
||||
Das Entfernungsverhalten von Nodes ändert sich, wenn ein Node in einer bestimmten Verfügbarkeitszone ungesund wird.
|
||||
Der Node-Controller überprüft gleichzeitig, wie viel Prozent der Nodes in der Zone ungesund sind (NodeReady-Bedingung ist ConditionUnknown oder ConditionFalse).
|
||||
Das Entfernungsverhalten von Nodes ändert sich, wenn ein Node in einer bestimmten Verfügbarkeitszone ungesund wird.
|
||||
Der Node-Controller überprüft gleichzeitig, wie viel Prozent der Nodes in der Zone ungesund sind (NodeReady-Bedingung ist ConditionUnknown oder ConditionFalse).
|
||||
Wenn der Anteil der ungesunden Nodes mindestens `--unhealthy-zone-threshold` (Standard 0,55) beträgt, wird die Entfernungsrate reduziert:
|
||||
|
||||
Wenn der Cluster klein ist (d.h. weniger als oder gleich `--large-cluster-size-threshold` Node - Standard 50), werden die Entfernungen gestoppt. Andernfalls wird die Entfernungsrate auf `--secondary-node-eviction-rate` (Standard 0,01) pro Sekunde reduziert.
|
||||
Wenn der Cluster klein ist (d.h. weniger als oder gleich `--large-cluster-size-threshold` Node - Standard 50), werden die Entfernungen gestoppt. Andernfalls wird die Entfernungsrate auf `--secondary-node-eviction-rate` (Standard 0,01) pro Sekunde reduziert.
|
||||
|
||||
Der Grund, warum diese Richtlinien pro Verfügbarkeitszone implementiert werden, liegt darin, dass eine Verfügbarkeitszone vom Master unerreichbar werden könnte, während die anderen verbunden bleiben. Wenn Ihr Cluster nicht mehrere Verfügbarkeitszonen von Cloud-Anbietern umfasst, gibt es nur eine Verfügbarkeitszone (den gesamten Cluster).
|
||||
|
||||
Ein wichtiger Grund für die Verteilung Ihrer Nodes auf Verfügbarkeitszonen ist, dass die Arbeitsbelastung auf gesunde Zonen verlagert werden kann, wenn eine ganze Zone ausfällt.
|
||||
Wenn also alle Nodes in einer Zone ungesund sind, entfernt Node Controller mit der normalen `--node-eviction-rate` Geschwindigkeit.
|
||||
Der Ausnahmefall ist, wenn alle Zonen völlig ungesund sind (d.h. es gibt keine gesunden Node im Cluster).
|
||||
Wenn also alle Nodes in einer Zone ungesund sind, entfernt Node Controller mit der normalen `--node-eviction-rate` Geschwindigkeit.
|
||||
Der Ausnahmefall ist, wenn alle Zonen völlig ungesund sind (d.h. es gibt keine gesunden Node im Cluster).
|
||||
In diesem Fall geht der Node-Controller davon aus, dass es ein Problem mit der Master-Konnektivität gibt und stoppt alle Entfernungen, bis die Verbindung wiederhergestellt ist.
|
||||
|
||||
Ab Kubernetes 1.6 ist der Node-Controller auch für die Entfernung von Pods zuständig, die auf Nodes mit `NoExecute`-Taints laufen, wenn die Pods die Markierungen nicht tolerieren.
|
||||
Zusätzlich ist der NodeController als Alpha-Funktion, die standardmäßig deaktiviert ist, dafür verantwortlich, Taints hinzuzufügen, die Node Probleme, wie `Node unreachable` oder `not ready` entsprechen.
|
||||
Ab Kubernetes 1.6 ist der Node-Controller auch für die Entfernung von Pods zuständig, die auf Nodes mit `NoExecute`-Taints laufen, wenn die Pods die Markierungen nicht tolerieren.
|
||||
Zusätzlich ist der NodeController als Alpha-Funktion, die standardmäßig deaktiviert ist, dafür verantwortlich, Taints hinzuzufügen, die Node Probleme, wie `Node unreachable` oder `not ready` entsprechen.
|
||||
Siehe [diese Dokumentation](/docs/concepts/configuration/taint-and-toleration/) für Details über `NoExecute` Taints und die Alpha-Funktion.
|
||||
|
||||
|
||||
@@ -198,7 +198,7 @@ Zur Selbstregistrierung wird das kubelet mit den folgenden Optionen gestartet:
|
||||
- `--node-labels` - Labels, die bei der Registrierung des Nodes im Cluster hinzugefügt werden sollen (Beachten Sie die Richlinien des [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) in 1.13+).
|
||||
- `--node-status-update-frequency` - Gibt an, wie oft kubelet den Nodestatus an den Master übermittelt.
|
||||
|
||||
Wenn der [Node authorization mode](/docs/reference/access-authn-authz/node/) und
|
||||
Wenn der [Node authorization mode](/docs/reference/access-authn-authz/node/) und
|
||||
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) aktiviert sind,
|
||||
dürfen kubelets nur ihre eigene Node-Ressource erstellen / ändern.
|
||||
|
||||
@@ -214,7 +214,7 @@ Zu den Änderungen gehören das Setzen von Labels und das Markieren des Nodes.
|
||||
Labels auf Nodes können in Verbindung mit node selectors auf Pods verwendet werden, um die Planung zu steuern, z.B. um einen Pod so zu beschränken, dass er nur auf einer Teilmenge der Nodes ausgeführt werden darf.
|
||||
|
||||
Das Markieren eines Nodes als nicht geplant, verhindert, dass neue Pods für diesen Node geplant werden. Dies hat jedoch keine Auswirkungen auf vorhandene Pods auf dem Node.
|
||||
Dies ist nützlich als vorbereitender Schritt vor einem Neustart eines Nodes usw.
|
||||
Dies ist nützlich als vorbereitender Schritt vor einem Neustart eines Nodes usw.
|
||||
Um beispielsweise einen Node als nicht geplant zu markieren, führen Sie den folgenden Befehl aus:
|
||||
|
||||
```shell
|
||||
@@ -222,7 +222,7 @@ kubectl cordon $NODENAME
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Pods, die von einem DaemonSet-Controller erstellt wurden, umgehen den Kubernetes-Scheduler und respektieren nicht das _unschedulable_ Attribut auf einem Node.
|
||||
Pods, die von einem DaemonSet-Controller erstellt wurden, umgehen den Kubernetes-Scheduler und respektieren nicht das _unschedulable_ Attribut auf einem Node.
|
||||
Dies setzt voraus, dass Daemons auf dem Computer verbleiben, auch wenn während der Vorbereitung eines Neustarts keine Anwendungen mehr vorhanden sind.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -234,7 +234,7 @@ Sofern Sie [Manuelle Nodeverwaltung](#Manuelle-Nodeverwaltung) betreiben, müsse
|
||||
|
||||
Der Kubernetes-Scheduler stellt sicher, dass für alle Pods auf einem Nodes genügend Ressourcen vorhanden sind.
|
||||
Er prüft, dass die Summe der Requests von Containern auf dem Node nicht größer ist als die Kapazität des Nodes.
|
||||
Er beinhaltet alle Container die vom kubelet gestarted worden, aber keine Container die direkt von der [container runtime](/docs/concepts/overview/components/#node-components) gestartet wurden, noch jegleiche Prozesse die ausserhalb von Containern laufen.
|
||||
Er beinhaltet alle Container die vom kubelet gestarted worden, aber keine Container die direkt von der [container runtime](/docs/concepts/overview/components/#node-components) gestartet wurden, noch jegleiche Prozesse die ausserhalb von Containern laufen.
|
||||
|
||||
Wenn Sie Ressourcen explizit für Nicht-Pod-Prozesse reservieren möchten, folgen Sie diesem Lernprogramm um [Ressourcen für Systemdaemons zu reservieren](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
|
||||
|
||||
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
title: Controller Manager Metriken
|
||||
content_template: templates/concept
|
||||
weight: 100
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
Controller Manager Metriken liefern wichtige Erkenntnisse über die Leistung und den Zustand von den Controller Managern.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## Was sind Controller Manager Metriken
|
||||
|
||||
Die Kennzahlen des Controller Managers liefert wichtige Erkenntnisse über die Leistung und den Zustand des Controller Managers.
|
||||
Diese Metriken beinhalten gängige Go Language Laufzeitmetriken wie go_routine count und controller-spezifische Metriken wie z.B.
|
||||
etcd Request Latenzen oder Cloud Provider (AWS, GCE, OpenStack) API Latenzen, die verwendet werden können um den Zustand eines Clusters zu messen.
|
||||
|
||||
Ab Kubernetes 1.7 stehen detaillierte Cloud Provider Metriken für den Speicherbetrieb für GCE, AWS, Vsphere und OpenStack zur Verfügung.
|
||||
Diese Metriken können verwendet werden, um den Zustand persistenter Datenträgeroperationen zu überwachen.
|
||||
|
||||
Für GCE werden diese Metriken beispielsweise wie folgt aufgerufen:
|
||||
|
||||
```
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
||||
```
|
||||
|
||||
## Konfiguration
|
||||
|
||||
In einem Cluster sind die Controller Manager Metriken unter `http://localhost:10252/metrics` auf dem Host verfügbar, auf dem der Controller Manager läuft.
|
||||
|
||||
Die Metriken werden im [Prometheus Format](https://prometheus.io/docs/instrumenting/exposition_formats/) ausgegeben.
|
||||
|
||||
In einer Produktionsumgebung können Sie Prometheus oder einen anderen Metrik Scraper konfigurieren, um diese Metriken regelmäßig zu sammeln und in einer Art Zeitreihen Datenbank verfügbar zu machen.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -1,64 +0,0 @@
|
||||
---
|
||||
title: Proxies in Kubernetes
|
||||
content_template: templates/concept
|
||||
weight: 90
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
Auf dieser Seite werden die im Kubernetes verwendeten Proxies erläutert.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Proxies
|
||||
|
||||
Es gibt mehrere verschiedene Proxies, die die bei der Verwendung von Kubernetes begegnen können:
|
||||
|
||||
1. Der [kubectl Proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
|
||||
|
||||
- läuft auf dem Desktop eines Benutzers oder in einem Pod
|
||||
- Proxy von einer lokalen Host-Adresse zum Kubernetes API Server
|
||||
- Client zu Proxy verwendet HTTP
|
||||
- Proxy zu API Server verwendet HTTPS
|
||||
- lokalisiert den API Server
|
||||
- fügt Authentifizierungs-Header hinzu
|
||||
|
||||
1. Der [API Server Proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
|
||||
|
||||
- ist eine Bastion, die in den API Server eingebaut ist
|
||||
- verbindet einen Benutzer außerhalb des Clusters mit Cluster IPs, die sonst möglicherweise nicht erreichbar wären
|
||||
- läuft im API Server Prozess
|
||||
- Client zu Proxy verwendet HTTPS (oder http, wenn API Server so konfiguriert ist)
|
||||
- Proxy zum Ziel kann HTTP oder HTTPS verwenden, der Proxy wählt dies unter Verwendung der verfügbaren Informationen aus
|
||||
- kann verwendet werden, um einen Knoten, Pod oder Service zu erreichen
|
||||
- führt einen Lastausgleich durch um einen Service zu erreichen, wenn dieser verwendet wird
|
||||
|
||||
1. Der [kube Proxy](/docs/concepts/services-networking/service/#ips-and-vips):
|
||||
|
||||
- läuft auf jedem Knoten
|
||||
- Proxy unterstüzt UDP, TCP und SCTP
|
||||
- versteht kein HTTP
|
||||
- stellt Lastausgleich zur Verfügung
|
||||
- wird nur zum erreichen von Services verwendet
|
||||
|
||||
1. Ein Proxy/Load-balancer vor dem API Server:
|
||||
|
||||
- Existenz und Implementierung variieren von Cluster zu Cluster (z.B. nginx)
|
||||
- sitzt zwischen allen Clients und einem oder mehreren API Servern
|
||||
- fungiert als Load Balancer, wenn es mehrere API Server gibt
|
||||
|
||||
1. Cloud Load Balancer für externe Services:
|
||||
|
||||
- wird von einigen Cloud Anbietern angeboten (z.B. AWS ELB, Google Cloud Load Balancer)
|
||||
- werden automatisch erstellt, wenn der Kubernetes Service den Typ `LoadBalancer` hat
|
||||
- unterstützt normalerweiße nur UDP/TCP
|
||||
- Die SCTP-Unterstützung hängt von der Load Balancer Implementierung des Cloud Providers ab
|
||||
- die Implementierung variiert je nach Cloud Anbieter
|
||||
|
||||
Kubernetes Benutzer müssen sich in der Regel um nichts anderes als die ersten beiden Typen kümmern. Der Cluster Administrator stellt in der Regel sicher, dass die letztgenannten Typen korrekt eingerichtet sind.
|
||||
|
||||
## Anforderung an Umleitungen
|
||||
|
||||
Proxies haben die Möglichkeit der Umleitung (redirect) ersetzt. Umleitungen sind veraltet.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -1,339 +0,0 @@
|
||||
---
|
||||
title: Images
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
{{% capture overview %}}
|
||||
|
||||
Sie erstellen ihr Docker Image und laden es in eine Registry hoch bevor es in einem Kubernetes Pod referenziert werden kann.
|
||||
|
||||
Die `image` Eigenschaft eines Containers unterstüzt die gleiche Syntax wie die des `docker` Kommandos, inklusive privater Registries und Tags.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Aktualisieren von Images
|
||||
|
||||
Die Standardregel für das Herunterladen von Images ist `IfNotPresent`, dies führt dazu das dass Kubelet Images überspringt die bereits auf einem Node vorliegen.
|
||||
Wenn sie stattdessen möchten das ein Image immer forciert heruntergeladen wird, können sie folgendes tun:
|
||||
|
||||
|
||||
- Die `imagePullPolicy` des Containers auf `Always` setzen.
|
||||
- Die `imagePullPolicy` auslassen und `:latest` als Image Tag nutzen.
|
||||
- Die `imagePullPolicy` und den Tag des Images auslassen.
|
||||
- Den [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) Admission Controller aktivieren.
|
||||
|
||||
Beachten Sie das die die Nutzung des `:latest` Tags vermeiden sollten, weitere Informationen siehe: [Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images).
|
||||
|
||||
## Multi-Architektur Images mit Manifesten bauen
|
||||
|
||||
Das Docker Kommandozeilenwerkzeug unterstützt jetzt das Kommando `docker manifest` mit den Subkommandos `create`, `annotate` and `push`.
|
||||
Diese Kommandos können dazu genutzt werden Manifeste zu bauen und diese hochzuladen.
|
||||
|
||||
Weitere Informationen finden sie in der Docker Dokumentation:
|
||||
https://docs.docker.com/edge/engine/reference/commandline/manifest/
|
||||
|
||||
Hier einige Beispiele wie wir dies in unserem Build - Prozess nutzen:
|
||||
https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos=
|
||||
|
||||
Diese Kommandos basieren rein auf dem Docker Kommandozeileninterface und werden auch damit ausgeführt. Sie sollten entweder die Datei `$HOME/.docker/config.json` bearbeiten und den `experimental` Schlüssel auf `enabled`setzen, oder einfach die Umgebungsvariable `DOCKER_CLI_EXPERIMENTAL` auf `enabled`setzen wenn Sie das Docker Kommandozeileninterface aufrufen.
|
||||
|
||||
|
||||
{{< note >}}
|
||||
Nutzen die bitte Docker *18.06 oder neuer*, ältere Versionen haben entweder bugs oder unterstützen die experimentelle Kommandozeilenoption nicht. Beispiel: https://github.com/docker/cli/issues/1135 verursacht Probleme unter containerd.
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
Wenn mit alten Manifesten Probleme auftreten können sie die alten Manifeste in `$HOME/.docker/manifests` entfernen um von vorne zu beginnen.
|
||||
|
||||
Für Kubernetes selbst haben wir typischerweise Images mit dem Suffix `-$(ARCH)` genutzt. Um die Abwärtskompatibilität zu erhalten bitten wir Sie die älteren Images mit diesen Suffixen zu generieren. Die Idee dahinter ist z.B. das `pause` image zu generieren, welches das Manifest für alle Architekturen hat, `pause-amd64` wäre dann abwärtskompatibel zu älteren Konfigurationen, oder YAML - Dateien die ein Image mit Suffixen hart kodiert haben.
|
||||
|
||||
|
||||
## Nutzung einer privaten Registry
|
||||
|
||||
Private Registries könnten Schlüssel erfordern um Images von ihnen herunterzuladen.
|
||||
Authentifizierungsdaten können auf verschiedene Weisen hinterlegt werden:
|
||||
|
||||
|
||||
- Bei der Google Container Registry
|
||||
- Je Cluster
|
||||
- Automatisch in der Google Compute Engine oder Google Kubernetes Engine
|
||||
- Allen Pods erlauben von der privaten Registry des Projektes lesen zu können
|
||||
- Bei der Amazon Elastic Container Registry (ECR)
|
||||
- IAM Rollen und Richtlinien nutzen um den Zugriff auf ECR Repositories zu kontrollieren
|
||||
- Automatisch ECR Authentifizierungsdaten aktualisieren
|
||||
- Bei der Oracle Cloud Infrastructure Registry (OCIR)
|
||||
- IAM Rollen und Richtlinien nutzen um den Zugriff auf OCIR Repositories zu kontrollieren
|
||||
- Bei der Azure Container Registry (ACR)
|
||||
- Bei der IBM Cloud Container Registry
|
||||
- Nodes konfigurieren sich bei einer privaten Registry authentifizieren zu können
|
||||
- Allen Pods erlauben von jeder konfigurierten privaten Registry lesen zu können
|
||||
- Setzt die Konfiguration der Nodes durch einen Cluster - Aministrator voraus
|
||||
- Im Voraus heruntergeladene Images
|
||||
- Alle Pods können jedes gecachte Image auf einem Node nutzen
|
||||
- Setzt root - Zugriff auf allen Nodes zum einrichten voraus
|
||||
- Spezifizieren eines ImagePullSecrets bei einem Pod
|
||||
- Nur Pods die eigene Schlüssel vorhalten haben Zugriff auf eine private Registry
|
||||
|
||||
Jeder Option wird im Folgenden im Detail beschrieben
|
||||
|
||||
|
||||
### Bei Nutzung der Google Container Registry
|
||||
|
||||
Kubernetes hat eine native Unterstützung für die [Google Container
|
||||
Registry (GCR)](https://cloud.google.com/tools/container-registry/) wenn es auf der Google Compute
|
||||
Engine (GCE) läuft. Wenn Sie ihren Cluster auf GCE oder der Google Kubernetes Engine betreiben, genügt es einfach den vollen Image Namen zu nutzen (z.B. gcr.io/my_project/image:tag ).
|
||||
|
||||
Alle Pods in einem Cluster haben dann lesenden Zugriff auf Images in dieser Registry.
|
||||
|
||||
Das Kubelet authentifiziert sich bei GCR mit Nutzung des Google service Kontos der jeweiligen Instanz.
|
||||
Das Google service Konto der Instanz hat einen `https://www.googleapis.com/auth/devstorage.read_only`, so kann es vom GCR des Projektes hochladen, aber nicht herunterladen.
|
||||
|
||||
|
||||
### Bei Nutzung der Amazon Elastic Container Registry
|
||||
|
||||
Kubernetes eine native Unterstützung für die [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) wenn Knoten AWS EC2 Instanzen sind.
|
||||
|
||||
Es muss einfah nur der komplette Image Name (z.B. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`) in der Pod - Definition genutzt werden.
|
||||
|
||||
Alle Benutzer eines Clusters die Pods erstellen dürfen können dann jedes der Images in der ECR Registry zum Ausführen von Pods nutzen.
|
||||
|
||||
Das Kubelet wird periodisch ECR Zugriffsdaten herunterladen und auffrischen, es benötigt hierfür die folgenden Berechtigungen:
|
||||
|
||||
- `ecr:GetAuthorizationToken`
|
||||
- `ecr:BatchCheckLayerAvailability`
|
||||
- `ecr:GetDownloadUrlForLayer`
|
||||
- `ecr:GetRepositoryPolicy`
|
||||
- `ecr:DescribeRepositories`
|
||||
- `ecr:ListImages`
|
||||
- `ecr:BatchGetImage`
|
||||
|
||||
Voraussetzungen:
|
||||
|
||||
- Sie müssen Kubelet in der Version `v1.2.0` nutzen. (Führen sie z.B. (e.g. run `/usr/bin/kubelet --version=true` aus um die Version zu prüfen)
|
||||
- Sie benötigen Version `v1.3.0` oder neuer wenn ihre Knoten in einer A - Region sind und sich ihre Registry in einer anderen B - Region befindet.
|
||||
- ECR muss in ihrer Region angeboten werden
|
||||
|
||||
Fehlerbehebung:
|
||||
|
||||
- Die oben genannten Voraussetzungen müssen erfüllt sein
|
||||
- Laden sie die $REGION (z.B. `us-west-2`) Zugriffsdaten auf ihren Arbeitsrechner. Verbinden sie sich per SSH auf den Host und nutzen die Docker mit diesen Daten. Funktioniert es?
|
||||
- Prüfen sie ob das Kubelet it dem Parameter `--cloud-provider=aws` läuft.
|
||||
- Prüfen sie die Logs des Kubelets (z.B. mit `journalctl -u kubelet`) auf Zeilen wie:
|
||||
- `plugins.go:56] Registering credential provider: aws-ecr-key`
|
||||
- `provider.go:91] Refreshing cache for provider: *aws_credentials.ecrProvider`
|
||||
|
||||
### Bei Nutzung der Azure Container Registry (ACR)
|
||||
Bei Nutzung der [Azure Container Registry](https://azure.microsoft.com/en-us/services/container-registry/) können sie sich entweder als ein administrativer Nutzer, oder als ein Service Principal authentifizieren
|
||||
In jedem Fall wird die Authentifizierung über die Standard - Docker Authentifizierung ausgeführt. Diese Anleitung bezieht sich auf das [azure-cli](https://github.com/azure/azure-cli) Kommandozeilenwerkzeug.
|
||||
|
||||
Sie müssen zunächst eine Registry und Authentifizierungsdaten erstellen, eine komplette Dokumentation dazu finden sie hier: [Azure container registry documentation](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli).
|
||||
|
||||
Sobald sie ihre Container Registry erstelt haben, nutzen sie die folgenden Authentifizierungsdaten:
|
||||
|
||||
* `DOCKER_USER` : Service Principal oder Administratorbenutzername
|
||||
* `DOCKER_PASSWORD`: Service Principal Password oder Administratorpasswort
|
||||
* `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io`
|
||||
* `DOCKER_EMAIL`: `${some-email-address}`
|
||||
|
||||
Wenn sie diese Variablen befüllt haben, können sie:
|
||||
[configure a Kubernetes Secret and use it to deploy a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
|
||||
|
||||
### Bei Nutzung der IBM Cloud Container Registry
|
||||
Die IBM Cloud Container Registry bietet eine mandantenfähige Private Image Registry die Sie nutzen können um ihre Docker Images sicher speichern und teilen zu können.
|
||||
Im Standard werden Images in ihrer Private Registry vom integrierten Schwachstellenscaner durchsucht um Sicherheitsprobleme und potentielle Schwachstellen zu finden. Benutzer können ihren IBM Cloud Account nutzen um Zugang zu ihren Images zu erhalten, oder um einen Token zu gernerieren, der Zugriff auf die Registry Namespaces erlaubt.
|
||||
|
||||
Um das IBM Cloud Container Registry Kommandozeilenwerkzeug zu installieren und einen Namespace für ihre Images zu erstellen, folgen sie dieser Dokumentation [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/services/Registry?topic=registry-getting-started).
|
||||
|
||||
Sie können die IBM Cloud Container Registry nutzen um Container aus [IBM Cloud public images](https://cloud.ibm.com/docs/services/Registry?topic=registry-public_images) und ihren eigenen Images in den `default` Namespace ihres IBM Cloud Kubernetes Service Clusters zu deployen.
|
||||
Um einen Container in einen anderen Namespace, oder um ein Image aus einer anderen IBM Cloud Container Registry Region oder einem IBM Cloud account zu deployen, erstellen sie ein Kubernetes `imagePullSecret`.
|
||||
Weitere Informationen finden sie unter: [Building containers from images](https://cloud.ibm.com/docs/containers?topic=containers-images).
|
||||
|
||||
### Knoten für die Nutzung einer Private Registry konfigurieren
|
||||
|
||||
{{< note >}}
|
||||
Wenn sie auf Google Kubernetes Engine laufen gibt es schon eine `.dockercfg` auf jedem Knoten die Zugriffsdaten für ihre Google Container Registry beinhaltet. Dann kann die folgende Vorgehensweise nicht angewendet werden.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Wenn sie auf AWS EC2 laufen und die EC2 Container Registry (ECR) nutzen, wird das Kubelet auf jedem Knoten die ECR Zugriffsdaten verwalten und aktualisieren. Dann kann die folgende Vorgehensweise nicht angewendet werden.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Diese Vorgehensweise ist anwendbar wenn sie ihre Knoten - Konfiguration ändern können, sie wird nicht zuverlässig auf GCE other einem anderen Cloud - Provider funktionieren der automatisch Knoten ersetzt.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Kubernetes unterstützt zur Zeit nur die `auths` und `HttpHeaders` Sektionen der Docker Konfiguration . Das bedeutet das die Hilfswerkzeuge (`credHelpers` ooderr `credsStore`) nicht unterstützt werden.
|
||||
{{< /note >}}
|
||||
|
||||
Docker speichert Schlüssel für eigene Registries in der Datei `$HOME/.dockercfg` oder `$HOME/.docker/config.json`. Wenn sie die gleiche Datei in einen der unten aufgeführten Suchpfade ablegen wird Kubelet sie als Hilfswerkzeug für Zugriffsdaten nutzen wenn es Images bezieht.
|
||||
|
||||
|
||||
* `{--root-dir:-/var/lib/kubelet}/config.json`
|
||||
* `{cwd of kubelet}/config.json`
|
||||
* `${HOME}/.docker/config.json`
|
||||
* `/.docker/config.json`
|
||||
* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
|
||||
* `{cwd of kubelet}/.dockercfg`
|
||||
* `${HOME}/.dockercfg`
|
||||
* `/.dockercfg`
|
||||
|
||||
{{< note >}}
|
||||
Eventuell müssen sie `HOME=/root` in ihrer Umgebungsvariablendatei setzen
|
||||
{{< /note >}}
|
||||
|
||||
Dies sind die empfohlenen Schritte um ihre Knoten für eine Nutzung einer eigenen Registry zu konfigurieren, in diesem Beispiel führen sie folgende Schritte auf ihrem Desktop/Laptop aus:
|
||||
|
||||
1. Führen sie `docker login [server]` für jeden Satz ihrer Zugriffsdaten aus. Dies aktualisiert `$HOME/.docker/config.json`.
|
||||
2. Prüfen Sie `$HOME/.docker/config.json` in einem Editor darauf ob dort nur Zugriffsdaten enthalten sind die Sie nutzen möchten.
|
||||
3. Erhalten sie eine Liste ihrer Knoten:
|
||||
- Wenn sie die Namen benötigen: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')`
|
||||
- Wenn sie die IP - Adressen benötigen: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')`
|
||||
4. Kopieren sie ihre lokale `.docker/config.json` in einen der oben genannten Suchpfade.
|
||||
- Zum Beispiel: `for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done`
|
||||
|
||||
Prüfen durch das Erstellen eines Pods der ein eigenes Image nutzt, z.B.:
|
||||
|
||||
```yaml
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: private-image-test-1
|
||||
spec:
|
||||
containers:
|
||||
- name: uses-private-image
|
||||
image: $PRIVATE_IMAGE_NAME
|
||||
imagePullPolicy: Always
|
||||
command: [ "echo", "SUCCESS" ]
|
||||
EOF
|
||||
pod/private-image-test-1 created
|
||||
```
|
||||
Wenn alles funktioniert sollten sie nach einigen Momenten folgendes sehen:
|
||||
|
||||
```shell
|
||||
kubectl logs private-image-test-1
|
||||
SUCCESS
|
||||
```
|
||||
Wenn es nicht funktioniert, sehen Sie:
|
||||
|
||||
```shell
|
||||
kubectl describe pods/private-image-test-1 | grep "Failed"
|
||||
Fri, 26 Jun 2015 15:36:13 -0700 Fri, 26 Jun 2015 15:39:13 -0700 19 {kubelet node-i2hq} spec.containers{uses-private-image} failed Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
|
||||
```
|
||||
|
||||
Sie müssen sich darum kümmern das alle Knoten im Cluster die gleiche `.docker/config.json` haben, anderenfalls werden Pods auf einigen Knoten starten, auf anderen jedoch nicht.
|
||||
Wenn sie zum Beispiel Knoten automatisch Skalieren lassen, sollte dann jedes Instanztemplate die `.docker/config.json` beinhalten, oder ein Laufwerk einhängen die diese beinhaltet.
|
||||
|
||||
Alle Pods haben Lesezugriff auf jedes Image in ihrer eigenen Registry sobald die Registry - Schlüssel zur `.docker/config.json` hinzugefügt wurden.
|
||||
|
||||
### Im Voraus heruntergeladene Images
|
||||
|
||||
{{< note >}}
|
||||
Wenn sie auf Google Kubernetes Engine laufen gibt es schon eine `.dockercfg` auf jedem Knoten die Zugriffsdaten für ihre Google Container Registry beinhaltet. Dann kann die folgende Vorgehensweise nicht angewendet werden.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Diese Vorgehensweise ist anwendbar wenn sie ihre Knoten - Konfiguration ändern können, sie wird nicht zuverlässig auf GCE other einem anderen Cloud - Provider funktionieren der automatisch Knoten ersetzt.
|
||||
{{< /note >}}
|
||||
|
||||
Im Standard wird das Kubelet versuchen jedes Image von der spezifizierten Registry herunterzuladen.
|
||||
Falls jedoch die `imagePullPolicy` Eigenschaft der Containers auf `IfNotPresent` oder `Never` gesetzt wurde, wird ein lokales Image genutzt (präferiert oder exklusiv, je nach dem).
|
||||
|
||||
Wenn Sie sich auf im Voraus heruntergeladene Images als Ersatz für eine Registry - Authentifizierung verlassen möchten, müssen sie sicherstellen das alle Knoten die gleichen im voraus heruntergeladenen Images aufweisen.
|
||||
|
||||
Diese Medthode kann dazu genutzt werden bestimmte Images aus Geschwindigkeitsgründen im Voraus zu laden, oder als Alternative zur Authentifizierung an einer eigenen Registry zu nutzen.
|
||||
|
||||
Alle Pods haben Leserechte auf alle im Voraus geladenen Images.
|
||||
|
||||
### Spezifizieren eines ImagePullSecrets für einen Pod
|
||||
|
||||
{{< note >}}
|
||||
Diese Vorgehensweise ist aktuell die empfohlene Vorgehensweise für Google Kubernetes Engine, GCE, und jeden Cloud - Provider bei dem die Knotenerstelltung automatisiert ist.
|
||||
{{< /note >}}
|
||||
|
||||
Kubernetes unterstützt die Spezifikation von Registrierungsschlüsseln für einen Pod.
|
||||
|
||||
#### Erstellung eines Secrets mit einer Docker Konfiguration
|
||||
|
||||
Führen sie foldenen Befehl mit Ersetzung der groß geschriebenen Werte aus:
|
||||
|
||||
```shell
|
||||
kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
|
||||
```
|
||||
|
||||
Wenn sie bereits eine Datei mit Docker Zugriffsdaten haben, könenn sie die Zugriffsdaten als ein Kubernetes Secret importieren:
|
||||
[Create a Secret based on existing Docker credentials](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) beschreibt die Erstellung.
|
||||
Dies ist insbesondere dann sinnvoll wenn sie mehrere eigene Container Registries nutzen, da `kubectl create secret docker-registry` ein Secret erstellt das nur mit einer einzelnen eigenen Registry funktioniert.
|
||||
|
||||
{{< note >}}
|
||||
Pods können nur eigene Image Pull Secret in ihrem eigenen Namespace referenzieren, somit muss dieser Prozess jedes mal einzeln für je Namespace angewendet werden.
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
#### Referenzierung eines imagePullSecrets bei einem Pod
|
||||
|
||||
Nun können sie Pods erstellen die dieses Secret referenzieren indem sie eine `imagePullSecrets` Sektion zu ihrer Pod - Definition hinzufügen.
|
||||
|
||||
```shell
|
||||
cat <<EOF > pod.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: foo
|
||||
namespace: awesomeapps
|
||||
spec:
|
||||
containers:
|
||||
- name: foo
|
||||
image: janedoe/awesomeapp:v1
|
||||
imagePullSecrets:
|
||||
- name: myregistrykey
|
||||
EOF
|
||||
|
||||
cat <<EOF >> ./kustomization.yaml
|
||||
resources:
|
||||
- pod.yaml
|
||||
EOF
|
||||
```
|
||||
|
||||
Dies muss für jeden Pod getan werden der eine eigene Registry nutzt.
|
||||
|
||||
Die Erstellung dieser Sektion kann jedoch automatisiert werden indem man imagePullSecrets einer serviceAccount](/docs/user-guide/service-accounts) Ressource hinzufügt.
|
||||
[Add ImagePullSecrets to a Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) bietet detaillierte Anweisungen hierzu.
|
||||
|
||||
Sie können dies in Verbindung mit einer auf jedem Knoten genutzten `.docker/config.json` benutzen, die Zugriffsdaten werden dann zusammengeführt. Dieser Vorgehensweise wird in der Google Kubernetes Engine funktionieren.
|
||||
|
||||
|
||||
### Anwendungsfälle
|
||||
|
||||
Es gibt eine Anzahl an Lösungen um eigene Registries zu konfigurieren, hier sind einige Anwendungsfälle und empfohlene Lösungen.
|
||||
|
||||
1. Cluster die nur nicht-proprietäre Images (z.B. open-source) ausführen. Images müssen nicht versteckt werden.
|
||||
- Nutzung von öffentlichen Images auf Docker Hub.
|
||||
- Keine Konfiguration notwendig.
|
||||
- Auf GCE/Google Kubernetes Engine, wird automatisch ein lokaler Spiegel für eine verbesserte Geschwindigkeit und Verfügbarkeit genutzt.
|
||||
2. Cluster die einige proprietäre Images ausführen die für Außenstehende nicht sichtbar sein dürfen, aber für alle Cluster - Benutzer sichtbar sein sollen.
|
||||
- Nutzung einer gehosteten privaten Registry [Docker registry](https://docs.docker.com/registry/).
|
||||
- Kann auf [Docker Hub](https://hub.docker.com/signup), oder woanders gehostet werden.
|
||||
- Manuelle Konfiguration der .docker/config.json auf jedem Knoten, wie oben beschrieben.
|
||||
- Der Betrieb einer internen privaten Registry hinter ihrer Firewall mit offenen Leseberechtigungen.
|
||||
- Keine Kubernetes - Konfiguration notwendig
|
||||
- Wenn GCE/Google Kubernetes Engine genutzt wird, nutzen sie die Google Container Registry des Projektes.
|
||||
- Funktioniert besser mit Cluster - Autoskalierung als mit manueller Knotenkonfiguration.
|
||||
- Auf einem Cluster bei dem die Knotenkonfiguration ungünstig ist können `imagePullSecrets` genutzt werden.
|
||||
3. Cluster mit proprieritären Images, mit einigen Images die eine erweiterte Zugriffskontrolle erfordern.
|
||||
- Stellen sie sicher das [AlwaysPullImages admission controller](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) aktiv ist, anderenfalls können alle Pods potenziell Zugriff auf alle Images haben.
|
||||
- Verschieben sie sensitive Daten in eine "Secret" Ressource statt sie im Image abzulegen.
|
||||
4. Ein mandantenfähiger Cluster in dem jeder Mandant eine eigene private Registry benötigt.
|
||||
- Stellen sie dicher das [AlwaysPullImages admission controller](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) aktiv ist, anderenfalls können alle Pods potenziell Zugriff auf alle Images haben.
|
||||
- Nutzen sie eine private Registry die eine Authorisierung erfordert.
|
||||
- Generieren die Registry - Zugriffsdaten für jeden Mandanten, abgelegt in einem Secret das in jedem Mandanten - Namespace vorhanden ist.
|
||||
- Der Mandant fügt dieses Sercret zu den imagePullSecrets in jedem seiner Namespace hinzu.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
Falls die Zugriff auf mehrere Registries benötigen, können sie ein Secret für jede Registry erstellen, Kubelet wird jedwede `imagePullSecrets` in einer einzelnen `.docker/config.json` zusammenfassen.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Kubernetes Komponenten
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
card:
|
||||
card:
|
||||
name: concepts
|
||||
weight: 20
|
||||
---
|
||||
@@ -50,7 +50,7 @@ Der cloud-controller-manager ist eine Alpha-Funktion, die in Kubernetes Version
|
||||
|
||||
cloud-controller-manager führt nur Cloud-Provider-spezifische Controller-Schleifen aus. Sie müssen diese Controller-Schleifen im Cube-Controller-Manager deaktivieren. Sie können die Controller-Schleifen deaktivieren, indem Sie beim Starten des kube-controller-manager das Flag `--cloud-provider` auf `external` setzen.
|
||||
|
||||
cloud-controller-manager erlaubt es dem Cloud-Anbieter Code und dem Kubernetes-Code, sich unabhängig voneinander zu entwickeln.
|
||||
cloud-controller-manager erlaubt es dem Cloud-Anbieter Code und dem Kubernetes-Code, sich unabhängig voneinander zu entwickeln.
|
||||
In früheren Versionen war der Kerncode von Kubernetes für die Funktionalität von Cloud-Provider-spezifischem Code abhängig.
|
||||
In zukünftigen Versionen sollte der für Cloud-Anbieter spezifische Code vom Cloud-Anbieter selbst verwaltet und mit dem Cloud-Controller-Manager verknüpft werden, während Kubernetes ausgeführt wird.
|
||||
|
||||
@@ -81,7 +81,7 @@ Kubernetes unterstützt mehrere Laufzeiten: [Docker](http://www.docker.com), [co
|
||||
## Addons
|
||||
|
||||
Addons sind Pods und Dienste, die Clusterfunktionen implementieren. Die Pods können verwaltet werden
|
||||
durch Deployments, ReplicationControllers, und so wieter.
|
||||
durch Deployments, ReplicationControllers, und so wieter.
|
||||
Namespace-Addon-Objekte werden im Namespace `kube-system` erstellt.
|
||||
|
||||
Ausgewählte Addons werden unten beschrieben. Eine erweiterte Liste verfügbarer Addons finden Sie unter [Addons](/docs/concepts/cluster-administration/addons/).
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Was ist Kubernetes?
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
card:
|
||||
card:
|
||||
name: concepts
|
||||
weight: 10
|
||||
---
|
||||
@@ -14,10 +14,10 @@ Diese Seite ist eine Übersicht über Kubernetes.
|
||||
{{% capture body %}}
|
||||
|
||||
Kubernetes ist eine portable, erweiterbare Open-Source-Plattform zur Verwaltung von
|
||||
containerisierten Arbeitslasten und Services, die sowohl die deklarative Konfiguration als auch die Automatisierung erleichtert.
|
||||
containerisierten Arbeitslasten und Services, die sowohl die deklarative Konfiguration als auch die Automatisierung erleichtert.
|
||||
Es hat einen großes, schnell wachsendes Ökosystem. Kubernetes Dienstleistungen, Support und Tools sind weit verbreitet.
|
||||
|
||||
Google hat das Kubernetes-Projekt 2014 als Open-Source-Projekt zur Verfügung gestellt. Kubernetes baut auf anderthalb Jahrzehnten
|
||||
Google hat das Kubernetes-Projekt 2014 als Open-Source-Projekt zur Verfügung gestellt. Kubernetes baut auf anderthalb Jahrzehnten
|
||||
Erfahrung auf, die Google mit der Ausführung von Produktions-Workloads in großem Maßstab hat, kombiniert mit den besten Ideen und Praktiken der Community.
|
||||
|
||||
## Warum brauche ich Kubernetes und was kann ich damit tun?
|
||||
@@ -29,65 +29,65 @@ Kubernetes hat eine Reihe von Funktionen. Es kann gesehen werden als:
|
||||
- eine portable Cloud-Plattform
|
||||
und vieles mehr.
|
||||
|
||||
Kubernetes bietet eine **containerzentrierte** Managementumgebung. Es koordiniert die Computer-, Netzwerk- und Speicherinfrastruktur
|
||||
im Namen der Benutzer-Workloads. Dies bietet einen Großteil der Einfachheit von Platform as a Service (PaaS) mit der Flexibilität
|
||||
Kubernetes bietet eine **containerzentrierte** Managementumgebung. Es koordiniert die Computer-, Netzwerk- und Speicherinfrastruktur
|
||||
im Namen der Benutzer-Workloads. Dies bietet einen Großteil der Einfachheit von Platform as a Service (PaaS) mit der Flexibilität
|
||||
von Infrastructure as a Service (IaaS) und ermöglicht die Portabilität zwischen Infrastrukturanbietern.
|
||||
|
||||
## Wie ist Kubernetes eine Plattform?
|
||||
|
||||
Auch wenn Kubernetes eine Menge Funktionalität bietet, gibt es immer wieder neue Szenarien,
|
||||
die von neuen Funktionen profitieren würden. Anwendungsspezifische Workflows können optimiert werden,
|
||||
um die Entwicklungsgeschwindigkeit zu beschleunigen.
|
||||
Eine zunächst akzeptable Ad-hoc-Orchestrierung erfordert oft eine robuste Automatisierung in großem Maßstab.
|
||||
Aus diesem Grund wurde Kubernetes auch als Plattform für den Aufbau eines Ökosystems von Komponenten und Tools
|
||||
Auch wenn Kubernetes eine Menge Funktionalität bietet, gibt es immer wieder neue Szenarien,
|
||||
die von neuen Funktionen profitieren würden. Anwendungsspezifische Workflows können optimiert werden,
|
||||
um die Entwicklungsgeschwindigkeit zu beschleunigen.
|
||||
Eine zunächst akzeptable Ad-hoc-Orchestrierung erfordert oft eine robuste Automatisierung in großem Maßstab.
|
||||
Aus diesem Grund wurde Kubernetes auch als Plattform für den Aufbau eines Ökosystems von Komponenten und Tools
|
||||
konzipiert, um die Bereitstellung, Skalierung und Verwaltung von Anwendungen zu erleichtern.
|
||||
|
||||
[Labels](/docs/concepts/overview/working-with-objects/labels/) ermöglichen es den Benutzern, ihre Ressourcen
|
||||
[Labels](/docs/concepts/overview/working-with-objects/labels/) ermöglichen es den Benutzern, ihre Ressourcen
|
||||
nach Belieben zu organisieren. [Anmerkungen](/docs/concepts/overview/working-with-objects/annotations/) ermöglichen es Benutzern,
|
||||
Ressourcen mit benutzerdefinierten Informationen zu versehen, um ihre Arbeitsabläufe zu vereinfachen und eine einfache Möglichkeit
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
## Was Kubernetes nicht ist
|
||||
|
||||
Kubernetes ist kein traditionelles, allumfassendes PaaS (Plattform als ein Service) System. Da Kubernetes nicht auf Hardware-,
|
||||
sondern auf Containerebene arbeitet, bietet es einige allgemein anwendbare Funktionen, die PaaS-Angeboten gemeinsam sind,
|
||||
wie Bereitstellung, Skalierung, Lastausgleich, Protokollierung und Überwachung.
|
||||
Kubernetes ist jedoch nicht monolithisch, und diese Standardlösungen sind optional und modular etweiterbar.
|
||||
Kubernetes liefert die Bausteine für den Aufbau von Entwicklerplattformen, bewahrt aber die
|
||||
Kubernetes ist kein traditionelles, allumfassendes PaaS (Plattform als ein Service) System. Da Kubernetes nicht auf Hardware-,
|
||||
sondern auf Containerebene arbeitet, bietet es einige allgemein anwendbare Funktionen, die PaaS-Angeboten gemeinsam sind,
|
||||
wie Bereitstellung, Skalierung, Lastausgleich, Protokollierung und Überwachung.
|
||||
Kubernetes ist jedoch nicht monolithisch, und diese Standardlösungen sind optional und modular etweiterbar.
|
||||
Kubernetes liefert die Bausteine für den Aufbau von Entwicklerplattformen, bewahrt aber die
|
||||
Wahlmöglichkeiten und Flexibilität der Benutzer, wo es wichtig ist.
|
||||
|
||||
Kubernetes:
|
||||
|
||||
* Schränkt nicht die Art der unterstützten Anwendungen ein. Kubernetes zielt darauf ab,
|
||||
eine extrem große Vielfalt von Workloads zu unterstützen, einschließlich stateless,
|
||||
stateful und datenverarbeitender Workloads. Wenn eine Anwendung in einem Container ausgeführt
|
||||
* Schränkt nicht die Art der unterstützten Anwendungen ein. Kubernetes zielt darauf ab,
|
||||
eine extrem große Vielfalt von Workloads zu unterstützen, einschließlich stateless,
|
||||
stateful und datenverarbeitender Workloads. Wenn eine Anwendung in einem Container ausgeführt
|
||||
werden kann, sollte sie auf Kubernetes hervorragend laufen.
|
||||
* Verteilt keinen Quellcode und entwickelt Ihre Anwendung nicht.
|
||||
Kontinuierliche Integrations-, Liefer- und Bereitstellungs-Workflows (CI/CD) werden durch
|
||||
* Verteilt keinen Quellcode und entwickelt Ihre Anwendung nicht.
|
||||
Kontinuierliche Integrations-, Liefer- und Bereitstellungs-Workflows (CI/CD) werden durch
|
||||
Unternehmenskulturen und -präferenzen sowie technische Anforderungen bestimmt.
|
||||
* Bietet keine Dienste auf Anwendungsebene, wie Middleware (z.B. Nachrichtenbusse),
|
||||
Datenverarbeitungs-Frameworks (z.B. Spark), Datenbanken (z.B. mysql), Caches oder
|
||||
Cluster-Speichersysteme (z.B. Ceph) als eingebaute Dienste. Solche Komponenten können
|
||||
auf Kubernetes laufen und/oder von Anwendungen, die auf Kubernetes laufen, über
|
||||
* Bietet keine Dienste auf Anwendungsebene, wie Middleware (z.B. Nachrichtenbusse),
|
||||
Datenverarbeitungs-Frameworks (z.B. Spark), Datenbanken (z.B. mysql), Caches oder
|
||||
Cluster-Speichersysteme (z.B. Ceph) als eingebaute Dienste. Solche Komponenten können
|
||||
auf Kubernetes laufen und/oder von Anwendungen, die auf Kubernetes laufen, über
|
||||
portable Mechanismen wie den Open Service Broker angesprochen werden.
|
||||
* Bietet keine Konfigurationssprache bzw. kein Konfigurationssystem (z.B.[jsonnet](https://github.com/google/jsonnet)).
|
||||
* Bietet keine Konfigurationssprache bzw. kein Konfigurationssystem (z.B.[jsonnet](https://github.com/google/jsonnet)).
|
||||
Es bietet eine deklarative API, die von beliebigen Formen deklarativer Spezifikationen angesprochen werden kann.
|
||||
* Bietet keine umfassenden Systeme zur Maschinenkonfiguration, Wartung, Verwaltung oder Selbstheilung.
|
||||
|
||||
Außerdem ist Kubernetes nicht nur ein *Orchestrierungssystem*. Fakt ist, dass es die Notwendigkeit einer Orchestrierung
|
||||
Außerdem ist Kubernetes nicht nur ein *Orchestrierungssystem*. Fakt ist, dass es die Notwendigkeit einer Orchestrierung
|
||||
überflüssig macht. Die technische Definition von *Orchestrierung* ist die Ausführung eines
|
||||
definierten Workflows: zuerst A, dann B, dann C. Im Gegensatz dazu besteht Kubernetes aus einer Reihe von unabhängigen,
|
||||
komponierbaren Steuerungsprozessen, die den aktuellen Zustand kontinuierlich in Richtung des bereitgestellten Soll-Zustandes vorantreiben.
|
||||
Es sollte keine Rolle spielen, wie Sie von A nach C kommen. Eine zentrale Steuerung ist ebenfalls nicht erforderlich.
|
||||
komponierbaren Steuerungsprozessen, die den aktuellen Zustand kontinuierlich in Richtung des bereitgestellten Soll-Zustandes vorantreiben.
|
||||
Es sollte keine Rolle spielen, wie Sie von A nach C kommen. Eine zentrale Steuerung ist ebenfalls nicht erforderlich.
|
||||
Das Ergebnis ist ein System, das einfacher zu bedienen und leistungsfähiger, robuster, widerstandsfähiger und erweiterbar ist.
|
||||
|
||||
## Warum Container?
|
||||
@@ -96,33 +96,33 @@ Sie suchen nach Gründen, warum Sie Container verwenden sollten?
|
||||
|
||||

|
||||
|
||||
Der *Altbekannte* Weg zur Bereitstellung von Anwendungen war die Installation
|
||||
Der *Altbekannte* Weg zur Bereitstellung von Anwendungen war die Installation
|
||||
der Anwendungen auf einem Host mit dem Betriebssystempaketmanager.
|
||||
Dies hatte den Nachteil, dass die ausführbaren Dateien, Konfigurationen,
|
||||
Bibliotheken und Lebenszyklen der Anwendungen untereinander und mit dem
|
||||
Host-Betriebssystem verwoben waren. Man könnte unveränderliche
|
||||
Virtual-Machine-Images erzeugen, um vorhersehbare Rollouts
|
||||
Dies hatte den Nachteil, dass die ausführbaren Dateien, Konfigurationen,
|
||||
Bibliotheken und Lebenszyklen der Anwendungen untereinander und mit dem
|
||||
Host-Betriebssystem verwoben waren. Man könnte unveränderliche
|
||||
Virtual-Machine-Images erzeugen, um vorhersehbare Rollouts
|
||||
und Rollbacks zu erreichen, aber VMs sind schwergewichtig und nicht portierbar.
|
||||
|
||||
Der *Neue Weg* besteht darin, Container auf Betriebssystemebene und nicht auf
|
||||
Hardware-Virtualisierung bereitzustellen. Diese Container sind voneinander
|
||||
und vom Host isoliert: Sie haben ihre eigenen Dateisysteme, sie können die
|
||||
Prozesse des anderen nicht sehen, und ihr Ressourcenverbrauch kann begrenzt
|
||||
werden. Sie sind einfacher zu erstellen als VMs, und da sie von der zugrunde
|
||||
liegenden Infrastruktur und dem Host-Dateisystem entkoppelt sind,
|
||||
Der *Neue Weg* besteht darin, Container auf Betriebssystemebene und nicht auf
|
||||
Hardware-Virtualisierung bereitzustellen. Diese Container sind voneinander
|
||||
und vom Host isoliert: Sie haben ihre eigenen Dateisysteme, sie können die
|
||||
Prozesse des anderen nicht sehen, und ihr Ressourcenverbrauch kann begrenzt
|
||||
werden. Sie sind einfacher zu erstellen als VMs, und da sie von der zugrunde
|
||||
liegenden Infrastruktur und dem Host-Dateisystem entkoppelt sind,
|
||||
sind sie über Clouds und Betriebssystem-Distributionen hinweg portabel.
|
||||
|
||||
Da Container klein und schnell sind, kann in jedes Containerimage eine Anwendung gepackt werden.
|
||||
Diese 1:1-Beziehung zwischen Anwendung und Image ermöglicht es, die Vorteile von Containern
|
||||
voll auszuschöpfen. Mit Containern können unveränderliche Container-Images eher zur Build-/Release-Zeit
|
||||
als zur Deployment-Zeit erstellt werden, da jede Anwendung nicht mit dem Rest des Anwendungsstacks komponiert
|
||||
werden muss und auch nicht mit der Produktionsinfrastrukturumgebung verbunden ist. Die Generierung von
|
||||
Container-Images zum Zeitpunkt der Erstellung bzw. Freigabe ermöglicht es, eine konsistente Umgebung
|
||||
von der Entwicklung bis zur Produktion zu gewährleisten.
|
||||
Ebenso sind Container wesentlich transparenter als VMs, was die Überwachung und Verwaltung erleichtert.
|
||||
Dies gilt insbesondere dann, wenn die Prozesslebenszyklen der Container von der Infrastruktur verwaltet
|
||||
Da Container klein und schnell sind, kann in jedes Containerimage eine Anwendung gepackt werden.
|
||||
Diese 1:1-Beziehung zwischen Anwendung und Image ermöglicht es, die Vorteile von Containern
|
||||
voll auszuschöpfen. Mit Containern können unveränderliche Container-Images eher zur Build-/Release-Zeit
|
||||
als zur Deployment-Zeit erstellt werden, da jede Anwendung nicht mit dem Rest des Anwendungsstacks komponiert
|
||||
werden muss und auch nicht mit der Produktionsinfrastrukturumgebung verbunden ist. Die Generierung von
|
||||
Container-Images zum Zeitpunkt der Erstellung bzw. Freigabe ermöglicht es, eine konsistente Umgebung
|
||||
von der Entwicklung bis zur Produktion zu gewährleisten.
|
||||
Ebenso sind Container wesentlich transparenter als VMs, was die Überwachung und Verwaltung erleichtert.
|
||||
Dies gilt insbesondere dann, wenn die Prozesslebenszyklen der Container von der Infrastruktur verwaltet
|
||||
werden und nicht von einem Prozess-Supervisor im Container versteckt werden.
|
||||
Schließlich, mit einer einzigen Anwendung pro Container, wird die Verwaltung
|
||||
Schließlich, mit einer einzigen Anwendung pro Container, wird die Verwaltung
|
||||
der Container gleichbedeutend mit dem Management des Deployments der Anwendung.
|
||||
|
||||
Zusammenfassung der Container-Vorteile:
|
||||
@@ -130,23 +130,23 @@ Zusammenfassung der Container-Vorteile:
|
||||
* **Agile Anwendungserstellung und -bereitstellung**:
|
||||
Einfachere und effizientere Erstellung von Container-Images im Vergleich zur Verwendung von VM-Images.
|
||||
* **Kontinuierliche Entwicklung, Integration und Bereitstellung**:
|
||||
Bietet eine zuverlässige und häufige Erstellung und Bereitstellung von Container-Images
|
||||
Bietet eine zuverlässige und häufige Erstellung und Bereitstellung von Container-Images
|
||||
mit schnellen und einfachen Rollbacks (aufgrund der Unveränderlichkeit des Images).
|
||||
* **Dev und Ops Trennung der Bedenken**:
|
||||
Erstellen Sie Anwendungscontainer-Images nicht zum Deployment-, sondern zum Build-Releasezeitpunkt
|
||||
Erstellen Sie Anwendungscontainer-Images nicht zum Deployment-, sondern zum Build-Releasezeitpunkt
|
||||
und entkoppeln Sie so Anwendungen von der Infrastruktur.
|
||||
* **Überwachbarkeit**
|
||||
Nicht nur Informationen und Metriken auf Betriebssystemebene werden angezeigt,
|
||||
Nicht nur Informationen und Metriken auf Betriebssystemebene werden angezeigt,
|
||||
sondern auch der Zustand der Anwendung und andere Signale.
|
||||
* **Umgebungskontinuität in Entwicklung, Test und Produktion**:
|
||||
Läuft auf einem Laptop genauso wie in der Cloud.
|
||||
* **Cloud- und OS-Distribution portabilität**:
|
||||
Läuft auf Ubuntu, RHEL, CoreOS, On-Prem, Google Kubernetes Engine und überall sonst.
|
||||
* **Anwendungsorientiertes Management**:
|
||||
Erhöht den Abstraktionsgrad vom Ausführen eines Betriebssystems auf virtueller Hardware
|
||||
Erhöht den Abstraktionsgrad vom Ausführen eines Betriebssystems auf virtueller Hardware
|
||||
bis zum Ausführen einer Anwendung auf einem Betriebssystem unter Verwendung logischer Ressourcen.
|
||||
* **Locker gekoppelte, verteilte, elastische, freie [micro-services](https://martinfowler.com/articles/microservices.html)**:
|
||||
Anwendungen werden in kleinere, unabhängige Teile zerlegt und können dynamisch bereitgestellt
|
||||
Anwendungen werden in kleinere, unabhängige Teile zerlegt und können dynamisch bereitgestellt
|
||||
und verwaltet werden -- nicht ein monolithischer Stack, der auf einer großen Single-Purpose-Maschine läuft.
|
||||
* **Ressourcenisolierung**:
|
||||
Vorhersehbare Anwendungsleistung.
|
||||
@@ -155,7 +155,7 @@ Zusammenfassung der Container-Vorteile:
|
||||
|
||||
## Was bedeutet Kubernetes? K8s?
|
||||
|
||||
Der Name **Kubernetes** stammt aus dem Griechischen, bedeutet *Steuermann* oder
|
||||
Der Name **Kubernetes** stammt aus dem Griechischen, beteutet *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.
|
||||
|
||||
@@ -8,11 +8,11 @@ weight: 80
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Wenn Sie an der Dokumentation oder der Website von Kubernetes mitwirken möchten, freuen wir uns über Ihre Hilfe!
|
||||
Wenn Sie an der Dokumentation oder der Website von Kubernetes mitwirken möchten, freuen wir uns über Ihre Hilfe!
|
||||
Jeder kann seinen Beitrag leisten, unabhängig davon ob Sie neu im Projekt sind oder schon lange dabei sind, und ob Sie sich als
|
||||
Entwickler, Endbenutzer oder einfach jemanden, der es einfach nicht aushält, Tippfehler zu sehen sehen.
|
||||
|
||||
Weitere Möglichkeiten, sich in der Kubernetes-Community zu engagieren oder mehr über uns zu erfahren, finden Sie auf der [Kubernetes-Community-Seite](/community/).
|
||||
Weitere Möglichkeiten, sich in der Kubernetes-Community zu engagieren oder mehr über uns zu erfahren, finden Sie auf der [Kubernetes-Community-Seite](/community/).
|
||||
Informationen zum Handbuch zur Dokumentation von Kubernetes finden Sie im [Gestaltungshandbuch](/docs/contribute/style/style-guide/).
|
||||
|
||||
{{% capture body %}}
|
||||
@@ -20,12 +20,12 @@ Informationen zum Handbuch zur Dokumentation von Kubernetes finden Sie im [Gesta
|
||||
## Arten von Mitwirkenden
|
||||
|
||||
- Ein _Member_ der Kubernetes Organisation, hat die [CLA unterzeichnet](/docs/contribute/start#sign-the-cla)
|
||||
und etwas Zeit und Energie zum Projekt beigetragen.
|
||||
Siehe [Community-Mitgliedschaft](https://github.com/kubernetes/community/blob/master/community-membership.md) für spezifische Kriterien bezüglich der Mitgliedschaft.
|
||||
- Ein SIG Docs _Reviewer_ ist ein Mitglied der Kubernetes-Organisation, das Interesse an der Überprüfung von
|
||||
Dokumentationsanfragen geäußert hat und von einem SIG Docs Approver zu der entsprechenden Github-Gruppe
|
||||
und etwas Zeit und Energie zum Projekt beigetragen.
|
||||
Siehe [Community-Mitgliedschaft](https://github.com/kubernetes/community/blob/master/community-membership.md) für spezifische Kriterien bezüglich der Mitgliedschaft.
|
||||
- Ein SIG Docs _Reviewer_ ist ein Mitglied der Kubernetes-Organisation, das Interesse an der Überprüfung von
|
||||
Dokumentationsanfragen geäußert hat und von einem SIG Docs Approver zu der entsprechenden Github-Gruppe
|
||||
und den `OWNERS`-Dateien im Github-Repository hinzugefügt wurde.
|
||||
- Ein SIG Docs _approver_ ist ein Mitglied mit gutem Ansehen, das sich kontinuierlich für das Projekt engagiert hat.
|
||||
- Ein SIG Docs _approver_ ist ein Mitglied mit gutem Ansehen, das sich kontinuierlich für das Projekt engagiert hat.
|
||||
Ein Approver kann Pull-Anfragen zusammenführen und Inhalte im Namen der Kubernetes-Organisation veröffentlichen.
|
||||
Approver können SIG Docs auch in der größeren Kubernetes-Community vertreten. Einige der Aufgaben eines SIG Docs Approvers, wie z.B. die Koordination einer Freigabe, erfordern einen erheblichen Zeitaufwand.
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ Dieser Abschnitt der Kubernetes-Dokumentation enthält Referenzinformationen.
|
||||
## API-Clientbibliotheken
|
||||
|
||||
Um die Kubernetes-API aus einer Programmiersprache aufzurufen, können Sie
|
||||
[Clientbibliotheken](/docs/reference/using-api/client-libraries/) verwenden.
|
||||
[Clientbibliotheken](/docs/reference/using-api/client-libraries/) verwenden.
|
||||
Offiziell unterstützte Clientbibliotheken:
|
||||
|
||||
- [Kubernetes Go Clientbibliothek](https://github.com/kubernetes/client-go/)
|
||||
|
||||
@@ -6,14 +6,14 @@ full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
|
||||
short_description: >
|
||||
Konsistenter und hochverfügbarer Key-Value Speicher, der als Backupspeicher von Kubernetes für alle Clusterdaten verwendet wird.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
- storage
|
||||
---
|
||||
Konsistenter und hochverfügbarer Key-Value Speicher, der als Backupspeicher von Kubernetes für alle Clusterdaten verwendet wird.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Halten Sie immer einen Sicherungsplan für etcds Daten für Ihren Kubernetes-Cluster bereit. Ausführliche Informationen zu etcd finden Sie in der [etcd Dokumentation](https://github.com/coreos/etcd/blob/master/Documentation/docs.md).
|
||||
|
||||
|
||||
@@ -4,16 +4,16 @@ id: kube-apiserver
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kube-apiserver/
|
||||
short_description: >
|
||||
Komponente auf dem Master, der die Kubernetes-API verfügbar macht. Es ist das Frontend für die Kubernetes-Steuerebene.
|
||||
Komponente auf dem Master, der die Kubernetes-API verfügbar macht. Es ist das Frontend für die Kubernetes-Steuerebene.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
- fundamental
|
||||
---
|
||||
Komponente auf dem Master, der die Kubernetes-API verfügbar macht. Es ist das Frontend für die Kubernetes-Steuerebene.
|
||||
Komponente auf dem Master, der die Kubernetes-API verfügbar macht. Es ist das Frontend für die Kubernetes-Steuerebene.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Es ist für die horizontale Skalierung konzipiert, d. H. Es skaliert durch die Bereitstellung von mehr Instanzen. Mehr informationen finden Sie unter [Cluster mit hoher Verfügbarkeit erstellen](/docs/admin/high-availability/).
|
||||
|
||||
|
||||
@@ -6,14 +6,14 @@ full_link: /docs/reference/generated/kube-controller-manager/
|
||||
short_description: >
|
||||
Komponente auf dem Master, auf dem Controller ausgeführt werden.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
- fundamental
|
||||
---
|
||||
Komponente auf dem Master, auf dem {{< glossary_tooltip text="controllers" term_id="controller" >}} ausgeführt werden.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Logisch gesehen ist jeder {{< glossary_tooltip text="controller" term_id="controller" >}} ein separater Prozess, aber zur Vereinfachung der Komplexität werden sie alle zu einer einzigen Binärdatei zusammengefasst und in einem einzigen Prozess ausgeführt.
|
||||
|
||||
|
||||
@@ -6,13 +6,13 @@ full_link: /docs/reference/generated/kube-scheduler/
|
||||
short_description: >
|
||||
Komponente auf dem Master, die neu erstellte Pods überwacht, denen kein Node zugewiesen ist. Sie wählt den Node aus, auf dem sie ausgeführt werden sollen.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
---
|
||||
Komponente auf dem Master, die neu erstellte Pods überwacht, denen kein Node zugewiesen ist. Sie wählt den Node aus, auf dem sie ausgeführt werden sollen.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Zu den Faktoren, die bei Planungsentscheidungen berücksichtigt werden, zählen individuelle und kollektive Ressourcenanforderungen, Hardware- / Software- / Richtlinieneinschränkungen, Affinitäts- und Anti-Affinitätsspezifikationen, Datenlokalität, Interworkload-Interferenz und Deadlines.
|
||||
|
||||
|
||||
@@ -6,13 +6,13 @@ full_link: /docs/reference/generated/kubelet
|
||||
short_description: >
|
||||
Ein Agent, der auf jedem Node im Cluster ausgeführt wird. Er stellt sicher, dass Container in einem Pod ausgeführt werden.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
---
|
||||
Ein Agent, der auf jedem Node im Cluster ausgeführt wird. Er stellt sicher, dass Container in einem Pod ausgeführt werden.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Das Kubelet verwendet eine Reihe von PodSpecs, die über verschiedene Mechanismen bereitgestellt werden, und stellt sicher, dass die in diesen PodSpecs beschriebenen Container ordnungsgemäß ausgeführt werden. Das kubelet verwaltet keine Container, die nicht von Kubernetes erstellt wurden.
|
||||
|
||||
@@ -55,7 +55,7 @@ KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view
|
||||
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
|
||||
|
||||
kubectl config view -o jsonpath='{.users[].name}' # eine Liste der Benutzer erhalten
|
||||
kubectl config current-context # den aktuellen Kontext anzeigen
|
||||
kubectl config current-context # den aktuellen Kontext anzeigen
|
||||
kubectl config use-context my-cluster-name # Setzen Sie den Standardkontext auf my-cluster-name
|
||||
|
||||
# Fügen Sie Ihrer kubeconf einen neuen Cluster hinzu, der basic auth unterstützt
|
||||
@@ -64,7 +64,7 @@ kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser -
|
||||
# Legen Sie einen Kontext fest, indem Sie einen bestimmten Benutzernamen und einen bestimmten Namespace verwenden.
|
||||
kubectl config set-context gce --user=cluster-admin --namespace=foo \
|
||||
&& kubectl config use-context gce
|
||||
|
||||
|
||||
kubectl config unset users.foo # delete user foo
|
||||
```
|
||||
|
||||
@@ -77,10 +77,10 @@ Kubernetes Manifeste können in Json oder Yaml definiert werden. Die Dateierweit
|
||||
`.yml`, und `.json` können verwendet werden.
|
||||
|
||||
```bash
|
||||
kubectl apply -f ./my-manifest.yaml # Ressource(n) erstellen
|
||||
kubectl apply -f ./my1.yaml -f ./my2.yaml # aus mehreren Dateien erstellen
|
||||
kubectl apply -f ./dir # Erstellen Sie Ressourcen in allen Manifestdateien in Verzeichnis
|
||||
kubectl apply -f https://git.io/vPieo # Ressource(n) aus URL erstellen
|
||||
kubectl apply -f ./my-manifest.yaml # Ressource(n) erstellen
|
||||
kubectl apply -f ./my1.yaml -f ./my2.yaml # aus mehreren Dateien erstellen
|
||||
kubectl apply -f ./dir # Erstellen Sie Ressourcen in allen Manifestdateien in Verzeichnis
|
||||
kubectl apply -f https://git.io/vPieo # Ressource(n) aus URL erstellen
|
||||
kubectl create deployment nginx --image=nginx # Starten Sie eine einzelne Instanz von Nginx
|
||||
kubectl explain pods,svc # Zeigen Sie die Dokumentation für Pod und SVC Manifeste an
|
||||
|
||||
@@ -133,7 +133,7 @@ kubectl get services # Listen Sie alle Dienste im Names
|
||||
kubectl get pods --all-namespaces # Listen Sie alle Pods in allen Namespaces auf
|
||||
kubectl get pods -o wide # Listen Sie alle Pods im Namespace mit weiteren Details auf
|
||||
kubectl get deployment my-dep # Listen Sie eine bestimmte Bereitstellung auf
|
||||
kubectl get pods # Listen Sie alle Pods im Namespace auf
|
||||
kubectl get pods --include-uninitialized # Listen Sie alle Pods im Namespace auf, einschließlich der nicht initialisierten
|
||||
|
||||
# Describe Befehle mit ausführlicher Ausgabe
|
||||
kubectl describe nodes my-node
|
||||
@@ -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 -o \
|
||||
kubectl get pods --selector=app=cassandra rc -o \
|
||||
jsonpath='{.items[*].metadata.labels.version}'
|
||||
|
||||
# Alle Worker-Knoten abrufen (verwenden Sie einen Selektor, um Ergebnisse auszuschließen,
|
||||
@@ -250,7 +250,8 @@ kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Skaliert meh
|
||||
kubectl delete -f ./pod.json # Löscht einen Pod mit dem in pod.json angegebenen Typ und Namen
|
||||
kubectl delete pod,service baz foo # Löscht Pods und Services mit den gleichen Namen "baz" und "foo"
|
||||
kubectl delete pods,services -l name=myLabel # Löscht Pods und Services mit dem Label name=myLabel
|
||||
kubectl -n my-ns delete po,svc --all # Löscht alle Pods und Dienste, im Namespace my-ns
|
||||
kubectl delete pods,services -l name=myLabel --include-uninitialized # Löscht Pods und Services, einschließlich nicht initialisierter, mit dem Label name=myLabel
|
||||
kubectl -n my-ns delete po,svc --all # Löscht alle Pods und Dienste, einschließlich nicht initialisierter, im Namespace my-ns,
|
||||
```
|
||||
|
||||
## Interaktion mit laufenden Pods
|
||||
@@ -321,7 +322,7 @@ Ausgabeformat | Beschreibung
|
||||
|
||||
### Kubectl Ausgabe Ausführlichkeit und Debugging
|
||||
|
||||
Die Ausführlichkeit von Kubectl wird mit den Flags `-v` oder `--v ` gesteuert, gefolgt von einer Ganzzahl, die die Protokollebene darstellt. Allgemeine Protokollierungskonventionen für Kubernetes und die zugehörigen Protokollebenen werden [hier](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) beschrieben.
|
||||
Die Ausführlichkeit von Kubectl wird mit den Flags `-v` oder `--v ` gesteuert, gefolgt von einer Ganzzahl, die die Protokollebene darstellt. Allgemeine Protokollierungskonventionen für Kubernetes und die zugehörigen Protokollebenen werden [hier](https://github.com/kubernetes/community/blob/master/contributors/devel/logging.md) beschrieben.
|
||||
|
||||
Ausführlichkeit | Beschreibung
|
||||
--------------| -----------
|
||||
|
||||
@@ -12,7 +12,7 @@ Kubernetes enthält mehrere integrierte Tools, die Ihnen bei der Arbeit mit dem
|
||||
|
||||
[`kubectl`](/docs/tasks/tools/install-kubectl/) ist ein Kommandozeilenprogramm für Kubernetes. Es steuert den Kubernetes Clustermanager.
|
||||
|
||||
## Kubeadm
|
||||
## Kubeadm
|
||||
|
||||
[`kubeadm`](/docs/setup/independent/install-kubeadm/) ist ein Kommandozeilenprogramm zur einfachen Bereitstellung eines sicheren Kubernetes-Clusters auf physischen oder Cloud-Servern oder virtuellen Maschinen (derzeit in alpha).
|
||||
|
||||
@@ -24,7 +24,7 @@ Kubernetes enthält mehrere integrierte Tools, die Ihnen bei der Arbeit mit dem
|
||||
|
||||
[`minikube`](/docs/tasks/tools/install-minikube/) ist ein Tool, das es Ihnen einfach macht, einen Kubernetes-Cluster mit einem einzigen Knoten lokal auf Ihrer Workstation für Entwicklungs- und Testzwecke auszuführen.
|
||||
|
||||
## Dashboard
|
||||
## Dashboard
|
||||
|
||||
[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), die webbasierte Benutzeroberfläche von Kubernetes ermöglicht es Ihnen containerisierte Anwendungen in einem Kubernetes-Cluster bereitzustellen Fehler zu beheben und den Cluster und seine Ressourcen selbst zu verwalten.
|
||||
|
||||
@@ -34,10 +34,10 @@ Kubernetes enthält mehrere integrierte Tools, die Ihnen bei der Arbeit mit dem
|
||||
|
||||
Verwenden Sie Helm um:
|
||||
|
||||
* Beliebte Software verpackt als Kubernetes charts zu finden und zu verwenden
|
||||
* Beliebte Software verpackt als Kubernetes charts zu finden und zu verwenden
|
||||
* Ihre eigenen Applikationen als Kubernetes charts zu teilen
|
||||
* Reproduzierbare Builds Ihrer Kubernetes Anwendungen zu erstellen
|
||||
* Intelligenten Verwaltung von Ihren Kubernetes manifest files
|
||||
* Intelligenten Verwaltung von Ihren Kubernetes manifest files
|
||||
* Verwalten von Versionen von Helm Paketen
|
||||
|
||||
## Kompose
|
||||
|
||||
@@ -18,7 +18,7 @@ Minikube ist ein Tool, mit dem Kubernetes lokal einfach ausgeführt werden kann.
|
||||
* NodePorts
|
||||
* ConfigMaps and Secrets
|
||||
* Dashboards
|
||||
* Container Laufzeiumgebungen: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://cri-o.io/) und [containerd](https://github.com/containerd/containerd)
|
||||
* Container Laufzeiumgebungen: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o) und [containerd](https://github.com/containerd/containerd)
|
||||
* Unterstützung von CNI (Container Network Interface)
|
||||
* Ingress
|
||||
|
||||
@@ -29,7 +29,7 @@ Lesen Sie [Minikube installieren](/docs/tasks/tools/install-minikube/) für Info
|
||||
## Schnellstart
|
||||
|
||||
Folgend finden Sie eine kurze Demo zur Verwendung von Minikube.
|
||||
Wenn Sie den VM-Treiber ändern möchten, fügen Sie das entsprechende `--vm-driver=xxx`-Flag zu `minikube start` hinzu.
|
||||
Wenn Sie den VM-Treiber ändern möchten, fügen Sie das entsprechende `--vm-driver=xxx`-Flag zu `minikube start` hinzu.
|
||||
Minikube unterstützt die folgenden Treiber:
|
||||
|
||||
* virtualbox
|
||||
@@ -52,20 +52,20 @@ Creating machine...
|
||||
Starting local Kubernetes cluster...
|
||||
```
|
||||
```shell
|
||||
kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
|
||||
kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.10 --port=8080
|
||||
```
|
||||
```
|
||||
deployment.apps/hello-minikube created
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl expose deployment hello-minikube --type=NodePort --port=8080
|
||||
kubectl expose deployment hello-minikube --type=NodePort
|
||||
```
|
||||
```
|
||||
service/hello-minikube exposed
|
||||
```
|
||||
```
|
||||
# Wir haben jetzt einen echoserver Pod gestartet, aber wir müssen warten,
|
||||
# Wir haben jetzt einen echoserver Pod gestartet, aber wir müssen warten,
|
||||
# bis der Pod betriebsbereit ist, bevor wir über den exponierten Dienst auf ihn zugreifen können.
|
||||
# Um zu überprüfen, ob der Pod läuft, können wir Folgendes verwenden:
|
||||
kubectl get pod
|
||||
@@ -164,7 +164,7 @@ minikube start \
|
||||
|
||||
#### CRI-O
|
||||
|
||||
Um [CRI-O](https://cri-o.io/) als Containerlaufzeitumgebung zu verwenden, führen Sie den folgenden Befehl aus:
|
||||
Um [CRI-O](https://github.com/kubernetes-incubator/cri-o) als Containerlaufzeitumgebung zu verwenden, führen Sie den folgenden Befehl aus:
|
||||
|
||||
```bash
|
||||
minikube start \
|
||||
|
||||
@@ -9,7 +9,7 @@ content_template: templates/concept
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Dieser Abschnitt der Kubernetes-Dokumentation enthält Seiten, die zeigen, wie man einzelne Aufgaben erledigt.
|
||||
Dieser Abschnitt der Kubernetes-Dokumentation enthält Seiten, die zeigen, wie man einzelne Aufgaben erledigt.
|
||||
Eine Aufgabenseite zeigt, wie man eine einzelne Aufgabe ausführt, typischerweise durch eine kurze Abfolge von Schritten.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -88,7 +88,7 @@ Schließlich, kurz bevor HPA das Ziel skaliert, wird die Skalierungsempfehlung a
|
||||
Der Horizontal Pod Autoscaler ist eine API Ressource in der Kubernetes `autoscaling` API Gruppe.
|
||||
Die aktuelle stabile Version, die nur die Unterstützung für die automatische Skalierung der CPU beinhaltet, befindet sich in der `autoscaling/v1` API Version.
|
||||
|
||||
Die Beta-Version, welche die Skalierung des Speichers und benutzerdefinierte Metriken unterstützt, befindet sich unter `autoscaling/v2beta2`. Die in `autoscaling/v2beta2` neu eingeführten Felder bleiben bei der Arbeit mit `autoscaling/v1` als Anmerkungen erhalten.
|
||||
Die Beta-Version, weclhe die Skalierung des Speichers und benutzerdefinierte Metriken unterstützt, befindet sich unter `autoscaling/v2beta2`. Die in `autoscaling/v2beta2` neu eingeführten Felder bleiben bei der Arbeit mit `autoscaling/v1` als Anmerkungen erhalten.
|
||||
|
||||
Weitere Details über das API Objekt kann unter dem [HorizontalPodAutoscaler Objekt](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object) gefunden werden.
|
||||
|
||||
@@ -131,7 +131,6 @@ Beim Abstimmen dieser Parameterwerte sollte sich ein Clusterbetreiber der mögli
|
||||
Kubernetes 1.6 bietet Unterstützung für die Skalierung basierend auf mehreren Metriken. Du kannst die API Version `autoscaling/v2beta2` verwenden, um mehrere Metriken für den Horizontal Pod Autoscaler zum Skalieren festzulegen. Anschließend wertet der Horizontal Pod Autoscaler Controller jede Metrik aus und schlägt eine neue Skalierung basierend auf diesen Metrik vor. Die größte der vorgeschlagenen Skalierung wird als neue Skalierung verwendet.
|
||||
|
||||
## Unterstützung von benutzerdefinierte Metriken
|
||||
|
||||
{{< note >}}
|
||||
Kubernetes 1.2 bietet Alpha Unterstützung für die Skalierung basierend auf anwendungsspezifischen Metriken über speziellen Annotations. Die Unterstützung für diese Annotations wurde in Kubernetes 1.6 zugunsten der neuen autoskalierenden API entfernt. Während die alte Methode zum Sammeln von benutzerdefinierten Metriken weiterhin verfügbar ist, stehen diese Metriken dem Horizontal Pod Autoscaler nicht mehr zur Verfügung, ebenso wenig wie die früheren Annotations zur Angabe, welche benutzerdefinierten Metriken zur Skalierung vom Horizontal Pod Autoscaler Controller berücksichtigt werden sollen.
|
||||
{{< /note >}}
|
||||
@@ -149,14 +148,14 @@ Standardmäßig ruft der HorizontalPodAutoscaler Controller Metriken aus einer R
|
||||
* Der [API Aggregations Layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) aktiviert ist.
|
||||
|
||||
* Die entsprechenden APIs registriert sind:
|
||||
|
||||
* Für Ressourcenmetriken ist dies die API `metrics.k8s.io`, die im Allgemeinen von [metrics-server](https://github.com/kubernetes-incubator/metrics-server) bereitgestellt wird.
|
||||
|
||||
* Für Ressourcenmetriken ist dies die API `metrics.k8s.io`, die im Allgemeinen von [metrics-server](https://github.com/kubernetes-incubator/metrics-server) bereitgestellt wird.
|
||||
Es kann als Cluster-Addon gestartet werden.
|
||||
|
||||
* Für benutzerdefinierte Metriken ist dies die API `custom.metrics.k8s.io`. Diese wird vom "Adapter" API Servern bereitgestellt, welches von Anbietern von Metrik Lösungen beliefert wird.
|
||||
Überprüfe dies mit deiner Metrik Pipeline oder der [Liste bekannter Lösungen](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api).
|
||||
Falls du deinen eigenen schreiben möchtest hilft dir folgender [boilerplate](https://github.com/kubernetes-incubator/custom-metrics-apiserver) um zu starten.
|
||||
|
||||
|
||||
* Für externe Metriken ist dies die `external.metrics.k8s.io` API. Es kann sein, dass dies durch den benutzerdefinierten Metrik Adapter bereitgestellt wird.
|
||||
|
||||
* Das Flag `--horizontal-pod-autoscaler-use-rest-clients` ist auf `true` oder ungesetzt. Wird dies auf `false` gesetzt wird die Heapster basierte Autoskalierung aktiviert, welche veraltet ist.
|
||||
|
||||
@@ -9,7 +9,7 @@ card:
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
Verwenden Sie das Kubernetes Befehlszeilenprogramm, [kubectl](/docs/user-guide/kubectl/), um Anwendungen auf Kubernetes bereitzustellen und zu verwalten.
|
||||
Verwenden Sie das Kubernetes Befehlszeilenprogramm, [kubectl](/docs/user-guide/kubectl/), um Anwendungen auf Kubernetes bereitzustellen und zu verwalten.
|
||||
Mit kubectl können Sie Clusterressourcen überprüfen, Komponenten erstellen, löschen und aktualisieren; Ihren neuen Cluster betrachten; und Beispielanwendungen aufrufen.
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -90,7 +90,7 @@ Wenn Sie mit macOS arbeiten und den [Macports](https://macports.org/) Paketmanag
|
||||
sudo port selfupdate
|
||||
sudo port install kubectl
|
||||
```
|
||||
|
||||
|
||||
2. Testen Sie, ob die installierte Version ausreichend aktuell ist:
|
||||
|
||||
```
|
||||
@@ -107,9 +107,9 @@ Wenn Sie mit Windows arbeiten und den [Powershell Gallery](https://www.powershel
|
||||
Install-Script -Name install-kubectl -Scope CurrentUser -Force
|
||||
install-kubectl.ps1 [-DownloadLocation <path>]
|
||||
```
|
||||
|
||||
|
||||
{{< note >}}Wenn Sie keine `DownloadLocation` angeben, wird `kubectl` im temporären Verzeichnis des Benutzers installiert.{{< /note >}}
|
||||
|
||||
|
||||
Das Installationsprogramm erstellt `$HOME/.kube` und weist es an, eine Konfigurationsdatei zu erstellen
|
||||
|
||||
2. Testen Sie, ob die installierte Version ausreichend aktuell ist:
|
||||
@@ -164,7 +164,7 @@ Um kubectl unter Windows zu installieren, können Sie entweder den Paketmanager
|
||||
```
|
||||
New-Item config -type file
|
||||
```
|
||||
|
||||
|
||||
{{< note >}}Bearbeiten Sie die Konfigurationsdatei mit einem Texteditor Ihrer Wahl, z.B. Notepad.{{< /note >}}
|
||||
|
||||
## Download als Teil des Google Cloud SDK herunter
|
||||
@@ -177,7 +177,7 @@ Sie können kubectl als Teil des Google Cloud SDK installieren.
|
||||
```
|
||||
gcloud components install kubectl
|
||||
```
|
||||
|
||||
|
||||
3. Testen Sie, ob die installierte Version ausreichend aktuell ist:
|
||||
|
||||
```
|
||||
@@ -190,14 +190,14 @@ Sie können kubectl als Teil des Google Cloud SDK installieren.
|
||||
{{% tab name="macOS" %}}
|
||||
1. Laden Sie die neueste Version herunter:
|
||||
|
||||
```
|
||||
```
|
||||
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
|
||||
```
|
||||
|
||||
Um eine bestimmte Version herunterzuladen, ersetzen Sie den Befehlsteil `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` mit der jeweiligen Version.
|
||||
|
||||
Um beispielsweise die Version {{< param "fullversion" >}} auf macOS herunterzuladen, verwenden Sie den folgenden Befehl:
|
||||
|
||||
|
||||
```
|
||||
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
|
||||
```
|
||||
@@ -225,7 +225,7 @@ Sie können kubectl als Teil des Google Cloud SDK installieren.
|
||||
Um eine bestimmte Version herunterzuladen, ersetzen Sie den Befehlsteil `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` mit der jeweiligen Version.
|
||||
|
||||
Um beispielsweise die Version {{< param "fullversion" >}} auf Linux herunterzuladen, verwenden Sie den folgenden Befehl:
|
||||
|
||||
|
||||
```
|
||||
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
|
||||
```
|
||||
@@ -243,7 +243,7 @@ Sie können kubectl als Teil des Google Cloud SDK installieren.
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Windows" %}}
|
||||
1. Laden Sie das aktuellste Release {{< param "fullversion" >}} von [diesem link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe) herunter.
|
||||
1. Laden Sie das aktuellste Release {{< param "fullversion" >}} von [disem link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe) herunter.
|
||||
|
||||
Oder, sofern Sie `curl` installiert haven, verwenden Sie den folgenden Befehl:
|
||||
|
||||
@@ -261,7 +261,7 @@ Sie können kubectl als Teil des Google Cloud SDK installieren.
|
||||
|
||||
## kubectl konfigurieren
|
||||
|
||||
Damit kubectl einen Kubernetes-Cluster finden und darauf zugreifen kann, benötigt es eine [kubeconfig Datei](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). Diese wird automatisch erstellt, wenn Sie einen Cluster mit [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) erstellen oder einen Minikube-Cluster erfolgreich implementieren. Weitere Informationen zum Erstellen von Clustern finden Sie in den [Anleitungen für die ersten Schritte](/docs/setup/). Wenn Sie Zugriff auf einen Cluster benötigen, den Sie nicht erstellt haben, lesen Sie die [Cluster-Zugriff freigeben Dokumentation](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
|
||||
Damit kubectl einen Kubernetes-Cluster finden und darauf zugreifen kann, benötigt es eine [kubeconfig Datei](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). Diese wird automatisch erstellt, wenn Sie einen Cluster mit kube-up.sh erstellen oder einen Minikube-Cluster erfolgreich implementieren. Weitere Informationen zum Erstellen von Clustern finden Sie in den [Anleitungen für die ersten Schritte](/docs/setup/). Wenn Sie Zugriff auf einen Cluster benötigen, den Sie nicht erstellt haben, lesen Sie die [Cluster-Zugriff freigeben Dokumentation](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
|
||||
Die kubectl-Konfiguration befindet sich standardmäßig unter `~/.kube/config`.
|
||||
|
||||
## Überprüfen der kubectl-Konfiguration
|
||||
|
||||
@@ -98,7 +98,7 @@ choco install minikube kubernetes-cli
|
||||
|
||||
Schließen Sie nach der Installation von Minikube die aktuelle CLI-Sitzung und starten Sie sie neu. Minikube sollte automatisch zu Ihrem Pfad hinzugefügt werden.
|
||||
|
||||
#### Manuelle installation unter Windows
|
||||
#### Manuelle installation unter Windows
|
||||
|
||||
Um Minikube manuell unter Windows zu installieren, laden Sie die Datei [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest) herunter, umbenennen Sie sie in `minikube.exe` und fügen Sie sie Ihrem Pfad zu.
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ content_template: templates/concept
|
||||
{{% capture overview %}}
|
||||
|
||||
Dieser Abschnitt der Kubernetes-Dokumentation enthält Tutorials.
|
||||
Ein Tutorial zeigt, wie Sie ein Ziel erreichen, das größer ist als eine einzelne [Aufgabe](/docs/tasks/).
|
||||
Ein Tutorial zeigt, wie Sie ein Ziel erreichen, das größer ist als eine einzelne [Aufgabe](/docs/tasks/).
|
||||
Ein Tutorial besteht normalerweise aus mehreren Abschnitten, die jeweils eine Abfolge von Schritten haben.
|
||||
Bevor Sie die einzelnen Lernprogramme durchgehen, möchten Sie möglicherweise ein Lesezeichen zur Seite mit dem [Standardisierten Glossar](/docs/reference/glossary/) setzen um später Informationen nachzuschlagen.
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ menu:
|
||||
weight: 10
|
||||
post: >
|
||||
<p>Sind Sie bereit, Ihre Hände schmutzig zu machen? Erstellen Sie einen einfachen Kubernetes-Cluster, auf dem "Hallo Welt" für Node.js ausgeführt wird.</p>
|
||||
card:
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 10
|
||||
---
|
||||
@@ -62,7 +62,7 @@ Weitere Informationen zum `docker build` Befehl, lesen Sie die [Docker Dokumenta
|
||||
|
||||
3. In einer Katacoda-Umgebung: Klicken Sie oben im Terminalbereich auf das Pluszeichen und anschließend auf **Select port to view on Host 1**.
|
||||
|
||||
4. In einer Katacoda-Umgebung: Geben Sie `30000` ein und klicken Sie dann auf **Display Port**.
|
||||
4. In einer Katacoda-Umgebung: Geben Sie `30000` ein und klicken Sie dann auf **Display Port**.
|
||||
|
||||
## Erstellen eines Deployments
|
||||
|
||||
@@ -71,8 +71,8 @@ Der Pod in diesem Tutorial hat nur einen Container.
|
||||
Ein Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) überprüft den Zustand Ihres Pods und startet den Container des Pods erneut, wenn er beendet wird.
|
||||
Deployments sind die empfohlene Methode zum Verwalten der Erstellung und Skalierung von Pods.
|
||||
|
||||
1. Verwenden Sie den Befehl `kubectl create`, um ein Deployment zu erstellen, die einen Pod verwaltet.
|
||||
Der Pod führt einen Container basierend auf dem bereitgestellten Docker-Image aus.
|
||||
1. Verwenden Sie den Befehl `kubectl create`, um ein Deployment zu erstellen, die einen Pod verwaltet.
|
||||
Der Pod führt einen Container basierend auf dem bereitgestellten Docker-Image aus.
|
||||
|
||||
```shell
|
||||
kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
|
||||
@@ -114,7 +114,7 @@ Der Pod führt einen Container basierend auf dem bereitgestellten Docker-Image a
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
|
||||
{{< note >}}Weitere Informationen zu `kubectl`-Befehlen finden Sie im [kubectl Überblick](/docs/user-guide/kubectl-overview/).{{< /note >}}
|
||||
|
||||
## Erstellen Sie einen Service
|
||||
@@ -127,7 +127,7 @@ Um den "Hallo-Welt"-Container außerhalb des virtuellen Netzwerks von Kubernetes
|
||||
```shell
|
||||
kubectl expose deployment hello-node --type=LoadBalancer --port=8080
|
||||
```
|
||||
|
||||
|
||||
Das Flag `--type = LoadBalancer` zeigt an, dass Sie Ihren Service außerhalb des Clusters verfügbar machen möchten.
|
||||
|
||||
2. Zeigen Sie den gerade erstellten Service an:
|
||||
@@ -160,7 +160,7 @@ Um den "Hallo-Welt"-Container außerhalb des virtuellen Netzwerks von Kubernetes
|
||||
|
||||
Daraufhin wird ein Browserfenster geöffnet, in dem Ihre App ausgeführt wird und die Meldung "Hello World" (Hallo Welt) angezeigt wird.
|
||||
|
||||
## Addons aktivieren
|
||||
## Addons aktivieren
|
||||
|
||||
Minikube verfügt über eine Reihe von integrierten Add-Ons, die in der lokalen Kubernetes-Umgebung aktiviert, deaktiviert und geöffnet werden können.
|
||||
|
||||
@@ -189,13 +189,13 @@ Minikube verfügt über eine Reihe von integrierten Add-Ons, die in der lokalen
|
||||
registry-creds: disabled
|
||||
storage-provisioner: enabled
|
||||
```
|
||||
|
||||
|
||||
2. Aktivieren Sie ein Addon, zum Beispiel `heapster`:
|
||||
|
||||
```shell
|
||||
minikube addons enable heapster
|
||||
```
|
||||
|
||||
|
||||
Ausgabe:
|
||||
|
||||
```shell
|
||||
@@ -232,7 +232,7 @@ Minikube verfügt über eine Reihe von integrierten Add-Ons, die in der lokalen
|
||||
```shell
|
||||
minikube addons disable heapster
|
||||
```
|
||||
|
||||
|
||||
Ausgabe:
|
||||
|
||||
```shell
|
||||
|
||||
@@ -14,8 +14,6 @@ card:
|
||||
|
||||
<body>
|
||||
|
||||
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
|
||||
|
||||
<div class="layout" id="top">
|
||||
|
||||
<main class="content">
|
||||
@@ -40,8 +38,8 @@ card:
|
||||
<div class="row">
|
||||
<div class="col-md-9">
|
||||
<h2>Was kann Kubernetes für Sie tun?</h2>
|
||||
<p>Bei modernen Webservices erwarten Benutzer, dass Anwendungen rund um die Uhr verfügbar sind, und Entwickler erwarten, mehrmals täglich neue Versionen dieser Anwendungen bereitzustellen (deployen).
|
||||
Containerisierung hilft bei der Paketierung von Software, um diese Ziele zu erreichen, sodass Anwendungen einfach und schnell ohne Ausfallzeiten veröffentlicht und aktualisiert werden können. Kubernetes hilft Ihnen dabei, sicherzustellen, dass diese Containeranwendungen immer dort laufen, wo und wann Sie möchten, und hilft Ihnen, die Ressourcen und Tools zu finden, die Sie zum Arbeiten benötigen. Kubernetes ist eine produktionsbereite Open-Source-Plattform, die auf der gesammelten Erfahrung von Google in der Container-Orchestrierung basiert und mit den besten Ideen der Community kombiniert wird.</p>
|
||||
<p>Bei modernen Webservices erwarten Benutzer, dass Anwendungen rund um die Uhr verfügbar sind, und Entwickler erwarten, mehrmals täglich neue Versionen dieser Anwendungen bereitzustellen (deployen).
|
||||
Containerisierung hilft bei der Paketierung von Software, um diese Ziele zu erreichen, sodass Anwendungen einfach und schnell ohne Ausfallzeiten veröffentlicht und aktualisiert werden können. Kubernetes hilft Ihnen dabei, sicherzustellen, dass diese Containeranwendungen immer dort laufen, wo und wann Sie möchten, und hilft ihnen, die Ressourcen und Tools zu finden, die sie zum Arbeiten benötigen. Kubernetes ist eine produktionsbereite Open-Source-Plattform, die auf der gesammelten Erfahrung von Google in der Container-Orchestrierung basiert und mit den besten Ideen der Community kombiniert wird.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
@@ -29,14 +29,14 @@ weight: 10
|
||||
<h3>Kubernetes-Bereitstellungen (Deployments)</h3>
|
||||
<p>
|
||||
Sobald Sie einen Kubernetes-Cluster ausgeführt haben, können Sie Ihre containerisierten Anwendungen darüber bereitstellen.
|
||||
Dazu erstellen Sie eine Kubernetes <b>Deployment</b>-Konfiguration. Das Deployment weist Kubernetes an, wie Instanzen Ihrer
|
||||
Anwendung erstellt und aktualisiert werden. Nachdem Sie ein Deployment erstellt haben, plant der Kubernetes-Master die genannten
|
||||
Dazu erstellen Sie eine Kubernetes <b>Deployment</b>-Konfiguration. Das Deployment weist Kubernetes an, wie Instanzen Ihrer
|
||||
Anwendung erstellt und aktualisiert werden. Nachdem Sie ein Deployment erstellt haben, plant der Kubernetes-Master die genannten
|
||||
Anwendungsinstanzen für einzelne Nodes im Cluster.
|
||||
</p>
|
||||
|
||||
<p>Sobald die Anwendungsinstanzen erstellt wurden, überwacht ein Kubernetes Deployment Controller diese Instanzen kontinuierlich. Wenn der Node, der eine Instanz hostet, ausfällt oder gelöscht wird, ersetzt der Deployment Controller die Instanz durch eine Instanz auf einem anderen Node im Cluster. <b>Dies bietet einen Selbstheilungsmechanismus, um Maschinenausfälle oder -wartungen zu vermeiden.</b></p>
|
||||
|
||||
<p>In einer Welt vor der Orchestrierung wurden häufig Installationsskripts zum Starten von Anwendungen verwendet, sie erlaubten jedoch keine Wiederherstellung nach einem Maschinenausfall.
|
||||
<p>In einer Welt vor der Orchestrierung wurden häufig Installationsskripts zum Starten von Anwendungen verwendet, sie erlaubten jedoch keine Wiederherstellung nach einem Maschinenausfall.
|
||||
Kubernetes Deployments erstellen Ihre Anwendungsinstanzen und sorgen dafür, dass sie über mehrere Nodes hinweg ausgeführt werden. Dadurch bieten Kubernetes Deployments einen grundlegend anderen Ansatz für die Anwendungsverwaltung.</p>
|
||||
|
||||
</div>
|
||||
@@ -74,7 +74,7 @@ weight: 10
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
|
||||
<p>Sie können eine Bereitstellung mithilfe der Kubernetes-Befehlszeilenschnittstelle <b>Kubectl</b> erstellen und verwalten.
|
||||
<p>Sie können eine Bereitstellung mithilfe der Kubernetes-Befehlszeilenschnittstelle <b>Kubectl</b> erstellen und verwalten.
|
||||
Kubectl verwendet die Kubernetes-API, um mit dem Cluster zu interagieren.
|
||||
In diesem Modul lernen Sie die gebräuchlichsten Kubectl-Befehle kennen, die zum Erstellen von Deployments zum Ausführen Ihrer Anwendungen in einem Kubernetes-Cluster erforderlich sind.</p>
|
||||
|
||||
|
||||
@@ -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 carousel-item active">
|
||||
<div class="item active">
|
||||
<img src="/docs/tutorials/kubernetes-basics/public/images/module_05_scaling1.svg">
|
||||
</div>
|
||||
|
||||
<div class="item carousel-item">
|
||||
<div class="item">
|
||||
<img src="/docs/tutorials/kubernetes-basics/public/images/module_05_scaling2.svg">
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
Dieses Handbuch geht davon aus, dass Sie eine laufende Installation der Kubernetes Cluster Federation haben.
|
||||
Dieses Handbuch geht davon aus, dass Sie eine laufende Installation der Kubernetes Cluster Federation haben.
|
||||
Wenn nicht, dann besuchen Sie den [Federation Admin Guide](/docs/tutorials/federation/set-up-cluster-federation-kubefed/), um zu lernen, wie man
|
||||
eine Cluster Federation erstellen kann (oder dies von Ihrem Cluster Administrator für Sie übernehmen lassen).
|
||||
Andere Tutorials, wie z.B. Kelsey Hightowers [Federated Kubernetes Tutorial](https://github.com/kelseyhightower/kubernetes-cluster-federation),
|
||||
|
||||
|
After Width: | Height: | Size: 1.9 KiB |
@@ -1 +0,0 @@
|
||||
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 214 210"><defs><style>.cls-1{fill:#316ce6;}.cls-2{fill:#09c1d1;}.cls-3{fill:#c9e9ec;}</style></defs><title>kubernetes_icons</title><rect class="cls-1" x="10.24" y="8.775" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="10.24" y="46.975" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="170.2" y="8.775" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="90.18" y="86.925" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="50.23" y="126.825" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="10.24" y="166.085" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="90.22" y="166.085" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="89.99" y="8.775" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="89.99" y="48.1" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="49.914" y="8.775" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="10.24" y="86.925" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="50.23" y="166.085" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="130.21" y="126.825" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="170.2" y="166.085" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="49.914" y="48.1" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="50.21" y="86.925" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="130.15" y="86.925" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="170.2" y="126.825" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="10.24" y="126.825" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="130.21" y="166.085" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="90.22" y="126.825" width="33.6" height="33.6" rx="4.158"/></svg>
|
||||
|
Before Width: | Height: | Size: 1.9 KiB |
|
After Width: | Height: | Size: 17 KiB |
|
Before Width: | Height: | Size: 14 KiB |
|
After Width: | Height: | Size: 1.8 KiB |
@@ -1 +0,0 @@
|
||||
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 214 210"><defs><style>.cls-1{fill:#316ce6;}.cls-2{fill:#08c1d1;}.cls-3{fill:#fff;}</style></defs><title>kubernetes_icons</title><rect class="cls-1" x="24.43837" y="69.59095" width="68.66984" height="68.66984" rx="2.37703" transform="translate(-56.27239 71.99817) rotate(-45)"/><rect class="cls-1" x="122.20077" y="69.59095" width="68.66984" height="68.66984" rx="2.37703" transform="translate(-27.63844 141.12663) rotate(-45)"/><rect class="cls-1" x="78.16563" y="128.81421" width="59.80067" height="59.80067" rx="2.07002" transform="translate(-80.57634 122.90059) rotate(-45)"/><rect class="cls-1" x="78.16563" y="19.38512" width="59.80067" height="59.80067" rx="2.07002" transform="translate(-3.19829 90.84955) rotate(-45)"/><rect class="cls-2" x="84.26447" y="80.01949" width="47.6109" height="47.6109" rx="5.89185" transform="translate(-41.76237 106.82659) rotate(-45)"/><rect class="cls-3" x="105.64189" y="55.09395" width="4.80943" height="43.28484"/><polygon class="cls-3" points="100.231 56.897 115.862 56.897 108.047 41.868 100.231 56.897"/><rect class="cls-3" x="114.14747" y="100.79333" width="43.28484" height="4.80943"/><polygon class="cls-3" points="155.629 95.382 155.629 111.013 170.658 103.198 155.629 95.382"/><rect class="cls-3" x="105.64143" y="109.47241" width="4.80943" height="43.28484"/><polygon class="cls-3" points="115.862 150.954 100.231 150.954 108.047 165.984 115.862 150.954"/><rect class="cls-3" x="58.69934" y="100.79348" width="43.28484" height="4.80943"/><polygon class="cls-3" points="60.503 111.013 60.503 95.382 45.474 103.198 60.503 111.013"/><circle class="cls-3" cx="107.94678" cy="103.92587" r="9.01768"/></svg>
|
||||
|
Before Width: | Height: | Size: 1.7 KiB |
|
After Width: | Height: | Size: 5.0 KiB |
|
Before Width: | Height: | Size: 5.2 KiB |
@@ -3,7 +3,6 @@ title: "Production-Grade Container Orchestration"
|
||||
abstract: "Automated container deployment, scaling, and management"
|
||||
cid: home
|
||||
---
|
||||
{{< announcement >}}
|
||||
|
||||
{{< deprecationwarning >}}
|
||||
|
||||
@@ -45,12 +44,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
|
||||
<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>
|
||||
<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.cn/kubecon-cloudnativecon-open-source-summit-china/" button id="desktopKCButton">Attend KubeCon in Shanghai on July 28-30, 2020</a>
|
||||
<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>
|
||||
</div>
|
||||
<div id="videoPlayer">
|
||||
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
|
||||
|
||||
@@ -2,11 +2,19 @@
|
||||
|
||||
# Owned by Kubernetes Blog reviewers
|
||||
|
||||
options:
|
||||
no_parent_owners: false
|
||||
|
||||
approvers:
|
||||
- sig-docs-blog-owners # Defined in OWNERS_ALIASES
|
||||
- kbarnard10
|
||||
- zacharysarah
|
||||
|
||||
reviewers:
|
||||
- sig-docs-blog-reviewers # Defined in OWNERS_ALIASES
|
||||
- vonguard
|
||||
- castrojo
|
||||
- mrbobbytables
|
||||
- cody-clark
|
||||
- parispittman
|
||||
|
||||
labels:
|
||||
- area/blog
|
||||
|
||||
@@ -50,7 +50,7 @@ Zend Server - The Complete PHP Application Platform
|
||||
|
||||
|
||||
|
||||
This list will grow, and is curated [here](https://opendev.org/x/k8s-docker-suite-app-murano/src/branch/master/Kubernetes). You can examine (and contribute to) the YAML file that tells Murano how to install and start the Kubernetes cluster [here](https://opendev.org/x/k8s-docker-suite-app-murano/src/branch/master/Kubernetes/KubernetesCluster/package/Classes/KubernetesCluster.yaml).
|
||||
This list will grow, and is curated [here](https://github.com/openstack/murano-apps/tree/master/Docker/Kubernetes). You can examine (and contribute to) the YAML file that tells Murano how to install and start the Kubernetes cluster [here](https://github.com/openstack/murano-apps/blob/master/Docker/Kubernetes/KubernetesCluster/package/Classes/KubernetesCluster.yaml).
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -30,19 +30,19 @@ When you start thinking in terms of Pods, there are naturally some general patte
|
||||
|
||||
Sidecar containers extend and enhance the "main" container, they take existing containers and make them better. As an example, consider a container that runs the Nginx web server. Add a different container that syncs the file system with a git repository, share the file system between the containers and you have built Git push-to-deploy. But you’ve done it in a modular manner where the git synchronizer can be built by a different team, and can be reused across many different web servers (Apache, Python, Tomcat, etc). Because of this modularity, you only have to write and test your git synchronizer once and reuse it across numerous apps. And if someone else writes it, you don’t even need to do that.
|
||||
|
||||

|
||||
[](https://3.bp.blogspot.com/-IVsNKDqS0jE/WRnPX21pxEI/AAAAAAAABJg/lAj3NIFwhPwvJYrmCdVbq1bqNq3E4AkhwCLcB/s1600/Example%2B%25231-%2BSidecar%2Bcontainers%2B.png)
|
||||
|
||||
## Example #2: Ambassador containers
|
||||
|
||||
Ambassador containers proxy a local connection to the world. As an example, consider a Redis cluster with read-replicas and a single write master. You can create a Pod that groups your main application with a Redis ambassador container. The ambassador is a proxy is responsible for splitting reads and writes and sending them on to the appropriate servers. Because these two containers share a network namespace, they share an IP address and your application can open a connection on “localhost” and find the proxy without any service discovery. As far as your main application is concerned, it is simply connecting to a Redis server on localhost. This is powerful, not just because of separation of concerns and the fact that different teams can easily own the components, but also because in the development environment, you can simply skip the proxy and connect directly to a Redis server that is running on localhost.
|
||||
|
||||

|
||||
[](https://4.bp.blogspot.com/-yEmqGZ86mNQ/WRnPYG1m3jI/AAAAAAAABJo/94DlN54LA-oTsORjEBHfHS_UQTIbNPvcgCEw/s1600/Example%2B%25232-%2BAmbassador%2Bcontainers.png)
|
||||
|
||||
## Example #3: Adapter containers
|
||||
|
||||
Adapter containers standardize and normalize output. Consider the task of monitoring N different applications. Each application may be built with a different way of exporting monitoring data. (e.g. JMX, StatsD, application specific statistics) but every monitoring system expects a consistent and uniform data model for the monitoring data it collects. By using the adapter pattern of composite containers, you can transform the heterogeneous monitoring data from different systems into a single unified representation by creating Pods that groups the application containers with adapters that know how to do the transformation. Again because these Pods share namespaces and file systems, the coordination of these two containers is simple and straightforward.
|
||||
|
||||

|
||||
[](https://4.bp.blogspot.com/-4rfSCMwvSwo/WRnPYLLQZqI/AAAAAAAABJk/c29uQgM2lSMHaUL013scJo_z4O8w38mJgCEw/s1600/Example%2B%25233-%2BAdapter%2Bcontainers%2B.png)
|
||||
|
||||
|
||||
In all of these cases, we've used the container boundary as an encapsulation/abstraction boundary that allows us to build modular, reusable components that we combine to build out applications. This reuse enables us to more effectively share containers between different developers, reuse our code across multiple applications, and generally build more reliable, robust distributed systems more quickly. I hope you’ve seen how Pods and composite container patterns can enable you to build robust distributed systems more quickly, and achieve container code re-use. To try these patterns out yourself in your own applications. I encourage you to go check out open source Kubernetes or Google Container Engine.
|
||||
|
||||
@@ -95,7 +95,7 @@ Mesosphere has incorporated Kubernetes into its Data Center Operating System (DC
|
||||
|
||||
|
|
||||
|
||||
[Platalytics, Inc][24]. and announced the release of one-touch deploy-anywhere feature for its Spark Application Platform. Based on Kubernetes, Docker, and CoreOS, it allows simple and automated deployment of Apache Hadoop, Spark, and Platalytics platform, with a single click, to all major public clouds, including Google, Amazon, Azure, DigitalOcean, and private on-premise clouds. It also enables hybrid cloud scenarios, where resources on public and private clouds can be mixed.
|
||||
[Platalytics, Inc][24]. and announced the release of one-touch deploy-anywhere feature for its Spark Application Platform. Based on Kubernetes, Docker, and CoreOS, it allows simple and automated deployment of Apache Hadoop, Spark, and Platalytics platform, with a single click, to all major public clouds, including Google, Amazon, Azure, Digital Ocean, and private on-premise clouds. It also enables hybrid cloud scenarios, where resources on public and private clouds can be mixed.
|
||||
|
||||
|
|
||||
|
|
||||
|
||||
@@ -146,6 +146,6 @@ Ahh, that’s better.
|
||||
|
||||
##### Conclusion
|
||||
|
||||
So there you have it, nine new and exciting things you can do with your Kubernetes cluster and the kubectl command line. If you’re just getting started with Kubernetes, check out [Google Container Engine](https://cloud.google.com/container-engine/) or other ways to [get started with Kubernetes](/docs/tutorials/kubernetes-basics/).
|
||||
So there you have it, nine new and exciting things you can do with your Kubernetes cluster and the kubectl command line. If you’re just getting started with Kubernetes, check out [Google Container Engine](https://cloud.google.com/container-engine/) or other ways to [get started with Kubernetes](http://kubernetes.io/gettingstarted/).
|
||||
|
||||
- Brendan Burns, Google Software Engineer
|
||||
|
||||
@@ -46,7 +46,7 @@ As we mentioned above, we would love your help:
|
||||
- Connect with the community on [Slack](http://slack.kubernetes.io/)
|
||||
- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
|
||||
- Post questions (or answer questions) on Stackoverflow
|
||||
- Get started running, deploying, and using Kubernetes [guides](/docs/tutorials/kubernetes-basics/);
|
||||
- Get started running, deploying, and using Kubernetes [guides](http://kubernetes.io/gettingstarted/)
|
||||
|
||||
But, most of all, just let us know how you are transforming your business using Kubernetes, and how we can help you do it even faster. Thank you for your support!
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ There are a seemingly infinite set of choices, with an infinite set of possible
|
||||
* [Amazon EC2](https://aws.amazon.com/ec2/) as our cloud platform, including RDS for persistence
|
||||
* [Docker Swarm](https://docs.docker.com/swarm/) as our "scheduler"
|
||||
* [Consul](https://consul.io/) for service discovery when bootstrapping Swarm
|
||||
* [Weave Net](https://www.weave.works/oss/net/) for our network and service discovery for the application itself
|
||||
* [Weave Net](http://weave.works/product/net/) for our network and service discovery for the application itself
|
||||
* [Terraform](https://terraform.io/) as our provisioner
|
||||
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ People familiar with [Puppet](https://github.com/puppetlabs/puppet) might h
|
||||
|
||||
### The Puppet Kubernetes Module
|
||||
|
||||
The Puppet Kubernetes module currently assumes you already have a Kubernetes cluster [up and running](/docs/tutorials/kubernetes-basics/);Its focus is on managing the resources in Kubernetes, like Pods, Replication Controllers and Services, not (yet) on managing the underlying kubelet or etcd services. Here’s a quick snippet of code describing a Pod in Puppet’s DSL.
|
||||
The Puppet Kubernetes module currently assumes you already have a Kubernetes cluster [up and running](http://kubernetes.io/gettingstarted/). Its focus is on managing the resources in Kubernetes, like Pods, Replication Controllers and Services, not (yet) on managing the underlying kubelet or etcd services. Here’s a quick snippet of code describing a Pod in Puppet’s DSL.
|
||||
|
||||
|
||||
```
|
||||
|
||||
@@ -6,7 +6,7 @@ url: /blog/2016/03/1000-Nodes-And-Beyond-Updates-To-Kubernetes-Performance-And-S
|
||||
---
|
||||
_Editor's note: this is the first in a [series of in-depth posts](https://kubernetes.io/blog/2016/03/five-days-of-kubernetes-12) on what's new in Kubernetes 1.2_
|
||||
|
||||
We're proud to announce that with the [release of 1.2](https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management), Kubernetes now supports 1000-node clusters, with a reduction of 80% in 99th percentile tail latency for most API operations. This means in just six months, we've increased our overall scale by 10 times while maintaining a great user experience — the 99th percentile pod startup times are less than 3 seconds, and 99th percentile latency of most API operations is tens of milliseconds (the exception being LIST operations, which take hundreds of milliseconds in very large clusters).
|
||||
We're proud to announce that with the [release of 1.2](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management-), Kubernetes now supports 1000-node clusters, with a reduction of 80% in 99th percentile tail latency for most API operations. This means in just six months, we've increased our overall scale by 10 times while maintaining a great user experience — the 99th percentile pod startup times are less than 3 seconds, and 99th percentile latency of most API operations is tens of milliseconds (the exception being LIST operations, which take hundreds of milliseconds in very large clusters).
|
||||
|
||||
Words are fine, but nothing speaks louder than a demo. Check this out!
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: " Building highly available applications using Kubernetes new multi-zone clusters (a.k.a. 'Ubernetes Lite') "
|
||||
date: 2016-03-29
|
||||
slug: building-highly-available-applications-using-kubernetes-new-multi-zone-clusters-a.k.a-ubernetes-lite
|
||||
url: /blog/2016/03/Building-Highly-Available-Applications-Using-Kubernetes-New-Multi-Zone-Clusters-aka-Ubernetes-Lite
|
||||
url: /blog/2016/03/Building-Highly-Available-Applications-Using-Kubernetes-New-Multi-Zone-Clusters-A.K.A-Ubernetes-Lite
|
||||
---
|
||||
_Editor's note: this is the third post in a [series of in-depth posts](https://kubernetes.io/blog/2016/03/five-days-of-kubernetes-12) on what's new in Kubernetes 1.2_
|
||||
|
||||
@@ -11,7 +11,7 @@ _Editor's note: this is the third post in a [series of in-depth posts](https://k
|
||||
### Introduction
|
||||
One of the most frequently-requested features for Kubernetes is the ability to run applications across multiple zones. And with good reason — developers need to deploy applications across multiple domains, to improve availability in thxe advent of a single zone outage.
|
||||
|
||||
[Kubernetes 1.2](https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management), released two weeks ago, adds support for running a single cluster across multiple failure zones (GCP calls them simply "zones," Amazon calls them "availability zones," here we'll refer to them as "zones"). This is the first step in a broader effort to allow federating multiple Kubernetes clusters together (sometimes referred to by the affectionate nickname "[Ubernetes](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/federation.md)"). This initial version (referred to as "Ubernetes Lite") offers improved application availability by spreading applications across multiple zones within a single cloud provider.
|
||||
[Kubernetes 1.2](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management-), released two weeks ago, adds support for running a single cluster across multiple failure zones (GCP calls them simply "zones," Amazon calls them "availability zones," here we'll refer to them as "zones"). This is the first step in a broader effort to allow federating multiple Kubernetes clusters together (sometimes referred to by the affectionate nickname "[Ubernetes](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/federation.md)"). This initial version (referred to as "Ubernetes Lite") offers improved application availability by spreading applications across multiple zones within a single cloud provider.
|
||||
|
||||
Multi-zone clusters are deliberately simple, and by design, very easy to use — no Kubernetes API changes were required, and no application changes either. You simply deploy your existing Kubernetes application into a new-style multi-zone cluster, and your application automatically becomes resilient to zone failures.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ date: 2016-03-28
|
||||
slug: five-days-of-kubernetes-12
|
||||
url: /blog/2016/03/Five-Days-Of-Kubernetes-12
|
||||
---
|
||||
The Kubernetes project has had some huge milestones over the past few weeks. We released [Kubernetes 1.2](https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management), had our [first conference in Europe](https://kubecon.io/), and were accepted into the [Cloud Native Computing Foundation](https://cncf.io/). While we catch our breath, we would like to take a moment to highlight some of the great work contributed by the community since our last milestone, just four months ago.
|
||||
The Kubernetes project has had some huge milestones over the past few weeks. We released [Kubernetes 1.2](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management-), had our [first conference in Europe](https://kubecon.io/), and were accepted into the [Cloud Native Computing Foundation](https://cncf.io/). While we catch our breath, we would like to take a moment to highlight some of the great work contributed by the community since our last milestone, just four months ago.
|
||||
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ Our mission is to make building distributed systems easy and accessible for all.
|
||||
|
|
||||
3/29
|
||||
|
|
||||
\* [Building highly available applications using Kubernetes new multi-zone clusters (a.k.a. Ubernetes Lite")](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-kubernetes-new-multi-zone-clusters-aka-ubernetes-lite/)
|
||||
\* [Building highly available applications using Kubernetes new multi-zone clusters (a.k.a. Ubernetes Lite")](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-Kubernetes-new-multi-zone-clusters-a.k.a-Ubernetes-Lite)
|
||||
\* Guest post by AppFormix: [Helping Enterprises Operationalize Kubernetes](https://kubernetes.io/blog/2016/03/appformix-helping-enterprises)
|
||||
|
|
||||
|
|
||||
@@ -32,7 +32,7 @@ Our mission is to make building distributed systems easy and accessible for all.
|
||||
|
|
||||
3/31
|
||||
|
|
||||
\* [Kubernetes 1.2 and simplifying advanced networking with Ingress](https://kubernetes.io/blog/2016/03/kubernetes-1-2-and-simplifying-advanced-networking-with-ingress/)
|
||||
\* [Kubernetes 1.2 and simplifying advanced networking with Ingress](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress)
|
||||
|
|
||||
|
|
||||
4/1
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: " Kubernetes 1.2 and simplifying advanced networking with Ingress "
|
||||
date: 2016-03-31
|
||||
slug: kubernetes-1.2-and-simplifying-advanced-networking-with-ingress
|
||||
url: /blog/2016/03/Kubernetes-1-2-And-Simplifying-Advanced-Networking-With-Ingress
|
||||
url: /blog/2016/03/Kubernetes-1.2-And-Simplifying-Advanced-Networking-With-Ingress
|
||||
---
|
||||
_Editor's note: This is the sixth post in a [series of in-depth posts](https://kubernetes.io/blog/2016/03/five-days-of-kubernetes-12) on what's new in Kubernetes 1.2._
|
||||
_Ingress is currently in beta and under active development._
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: " Kubernetes 1.2: Even more performance upgrades, plus easier application deployment and management "
|
||||
date: 2016-03-17
|
||||
slug: kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management
|
||||
url: /blog/2016/03/Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management
|
||||
url: /blog/2016/03/Kubernetes-1.2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management
|
||||
---
|
||||
Today we released Kubernetes 1.2. This release represents significant improvements for large organizations building distributed systems. Now with over 680 unique contributors to the project, this release represents our largest yet.
|
||||
|
||||
|
||||
@@ -42,7 +42,7 @@ Our heaviest use of the Kubernetes API is definitely our system of creating dyna
|
||||
|
||||
**Ingresses**
|
||||
|
||||
In order to provide a backend for HTTP API calls and allow self-registration of handlers we make use of the Ingress system in Kubernetes. It wasn't the clearest thing to set up, but reading through enough of the [nginx example](https://kubernetes.io/blog/2016/03/kubernetes-1-2-and-simplifying-advanced-networking-with-ingress/) eventually got us to a good spot where it is easy to connect services to the frontend.
|
||||
In order to provide a backend for HTTP API calls and allow self-registration of handlers we make use of the Ingress system in Kubernetes. It wasn't the clearest thing to set up, but reading through enough of the [nginx example](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress) eventually got us to a good spot where it is easy to connect services to the frontend.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,9 +4,9 @@ date: 2016-07-12
|
||||
slug: autoscaling-in-kubernetes
|
||||
url: /blog/2016/07/Autoscaling-In-Kubernetes
|
||||
---
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_
|
||||
|
||||
Customers using Kubernetes respond to end user requests quickly and ship software faster than ever before. But what happens when you build a service that is even more popular than you planned for, and run out of compute? In [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), we are proud to announce that we have a solution: autoscaling. On [Google Compute Engine](https://cloud.google.com/compute/) (GCE) and [Google Container Engine](https://cloud.google.com/container-engine/) (GKE) (and coming soon on [AWS](https://aws.amazon.com/)), Kubernetes will automatically scale up your cluster as soon as you need it, and scale it back down to save you money when you don’t.
|
||||
Customers using Kubernetes respond to end user requests quickly and ship software faster than ever before. But what happens when you build a service that is even more popular than you planned for, and run out of compute? In [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), we are proud to announce that we have a solution: autoscaling. On [Google Compute Engine](https://cloud.google.com/compute/) (GCE) and [Google Container Engine](https://cloud.google.com/container-engine/) (GKE) (and coming soon on [AWS](https://aws.amazon.com/)), Kubernetes will automatically scale up your cluster as soon as you need it, and scale it back down to save you money when you don’t.
|
||||
|
||||
|
||||
### Benefits of Autoscaling
|
||||
|
||||
@@ -21,7 +21,7 @@ I wish all our experiences working together with a technical partner were as goo
|
||||
|
||||
Next, NetScaler CPX needed to be inserted in the data path of GCP ingress load balancer so that NetScaler CPX can spread traffic to front end web servers. The NetScaler team made modifications so that NetScaler CPX listens to API server events and configures itself to create a VIP, IP table rules and server rules to take ingress traffic and load balance across front end applications. Google Cloud Platform team provided feedback and assistance to verify modifications made to overcome the technical hurdles. Done!
|
||||
|
||||
NetScaler CPX use case is supported in [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). Citrix customers and the broader enterprise market will have the opportunity to leverage NetScaler with Kubernetes, thereby lowering the friction to move workloads to the cloud.
|
||||
NetScaler CPX use case is supported in [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). Citrix customers and the broader enterprise market will have the opportunity to leverage NetScaler with Kubernetes, thereby lowering the friction to move workloads to the cloud.
|
||||
|
||||
You can learn more about NetScaler CPX [here](https://www.citrix.com/networking/microservices.html).
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ slug: cross-cluster-services
|
||||
url: /blog/2016/07/Cross-Cluster-Services
|
||||
---
|
||||
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_
|
||||
|
||||
As Kubernetes users scale their production deployments we’ve heard a clear desire to deploy services across zone, region, cluster and cloud boundaries. Services that span clusters provide geographic distribution, enable hybrid and multi-cloud scenarios and improve the level of high availability beyond single cluster multi-zone deployments. Customers who want their services to span one or more (possibly remote) clusters, need them to be reachable in a consistent manner from both within and outside their clusters.
|
||||
|
||||
|
||||
@@ -5,13 +5,13 @@ slug: dashboard-web-interface-for-kubernetes
|
||||
url: /blog/2016/07/Dashboard-Web-Interface-For-Kubernetes
|
||||
---
|
||||
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_
|
||||
|
||||
[Kubernetes Dashboard](http://github.com/kubernetes/dashboard) is a project that aims to bring a general purpose monitoring and operational web interface to the Kubernetes world. Three months ago we [released](https://kubernetes.io/blog/2016/04/building-awesome-user-interfaces-for-kubernetes) the first production ready version, and since then the dashboard has made massive improvements. In a single UI, you’re able to perform majority of possible interactions with your Kubernetes clusters without ever leaving your browser. This blog post breaks down new features introduced in the latest release and outlines the roadmap for the future.
|
||||
|
||||
**Full-Featured Dashboard**
|
||||
|
||||
Thanks to a large number of contributions from the community and project members, we were able to deliver many new features for [Kubernetes 1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). We have been carefully listening to all the great feedback we have received from our users (see the [summary infographics](http://static.lwy.io/img/kubernetes_dashboard_infographic.png)) and addressed the highest priority requests and pain points.
|
||||
Thanks to a large number of contributions from the community and project members, we were able to deliver many new features for [Kubernetes 1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). We have been carefully listening to all the great feedback we have received from our users (see the [summary infographics](http://static.lwy.io/img/kubernetes_dashboard_infographic.png)) and addressed the highest priority requests and pain points.
|
||||
|
||||
The Dashboard UI now handles all workload resources. This means that no matter what workload type you run, it is visible in the web interface and you can do operational changes on it. For example, you can modify your stateful MySQL installation with [Pet Sets](/docs/user-guide/petset/), do a rolling update of your web server with Deployments or install cluster monitoring with DaemonSets.
|
||||
|
||||
|
||||
@@ -2,9 +2,9 @@
|
||||
title: " Five Days of Kubernetes 1.3 "
|
||||
date: 2016-07-11
|
||||
slug: five-days-of-kubernetes-1.3
|
||||
url: /blog/2016/07/Five-Days-Of-Kubernetes-1-3
|
||||
url: /blog/2016/07/Five-Days-Of-Kubernetes-1.3
|
||||
---
|
||||
Last week we [released Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), two years from the day when the first Kubernetes commit was pushed to GitHub. Now 30,000+ commits later from over 800 contributors, this 1.3 releases is jam packed with updates driven by feedback from users.
|
||||
Last week we [released Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), two years from the day when the first Kubernetes commit was pushed to GitHub. Now 30,000+ commits later from over 800 contributors, this 1.3 releases is jam packed with updates driven by feedback from users.
|
||||
|
||||
While many new improvements and features have been added in the latest release, we’ll be highlighting several that stand-out. Follow along and read these in-depth posts on what’s new and how we continue to make Kubernetes the best way to manage containers at scale.
|
||||
|
||||
@@ -43,7 +43,7 @@ Day 5
|
||||
|
|
||||
Bonus
|
||||
|
|
||||
\* [Updates to Performance and Scalability](https://kubernetes.io/blog/2016/07/update-on-kubernetes-for-windows-server-containers/)
|
||||
\* [Updates to Performance and Scalability](https://kubernetes.io/blog/2016/07/kubernetes-updates-to-performance-and-scalability-in-1.3)
|
||||
|
|
||||
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: " Kubernetes 1.3: Bridging Cloud Native and Enterprise Workloads "
|
||||
date: 2016-07-06
|
||||
slug: kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads
|
||||
url: /blog/2016/07/Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads
|
||||
url: /blog/2016/07/Kubernetes-1.3-Bridging-Cloud-Native-And-Enterprise-Workloads
|
||||
---
|
||||
Nearly two years ago, when we officially kicked off the Kubernetes project, we wanted to simplify distributed systems management and provide the core technology required to everyone. The community’s response to this effort has blown us away. Today, thousands of customers, partners and developers are running clusters in production using Kubernetes and have joined the cloud native revolution.
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ Kubernetes was the first external orchestration platform supported by [Rancher](
|
||||
|
||||
### Rancher and Kubernetes 1.2
|
||||
|
||||
Kubernetes 1.2 introduced enhanced Ingress object to simplify allowing inbound connections to reach the cluster services: here’s an excellent [blog post about ingress](https://kubernetes.io/blog/2016/03/kubernetes-1-2-and-simplifying-advanced-networking-with-ingress/) policies. Ingress resource allows users to define host name routing rules and TLS config for the Load Balancer in a user friendly way. Then it should be backed up by an Ingress controller that would configure a corresponding cloud provider’s Load Balancer with the Ingress rules. Since Rancher already included a software defined Load Balancer based on HAproxy, we already supported all of the configuration requirements of the Ingress resource, and didn’t have to do any changes on the Rancher side to adopt Ingress. What we had to do was write an Ingress controller that would listen to Kubernetes ingress specific events, configure the Rancher Load Balancer accordingly, and propagate the Load Balancer public entry point back to Kubernetes:
|
||||
Kubernetes 1.2 introduced enhanced Ingress object to simplify allowing inbound connections to reach the cluster services: here’s an excellent [blog post about ingress](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress) policies. Ingress resource allows users to define host name routing rules and TLS config for the Load Balancer in a user friendly way. Then it should be backed up by an Ingress controller that would configure a corresponding cloud provider’s Load Balancer with the Ingress rules. Since Rancher already included a software defined Load Balancer based on HAproxy, we already supported all of the configuration requirements of the Ingress resource, and didn’t have to do any changes on the Rancher side to adopt Ingress. What we had to do was write an Ingress controller that would listen to Kubernetes ingress specific events, configure the Rancher Load Balancer accordingly, and propagate the Load Balancer public entry point back to Kubernetes:
|
||||
|
||||
|
||||
|
||||
@@ -155,7 +155,7 @@ Then every underlying Kubernetes cluster represented by Rancher environment, sho
|
||||
|
||||
|
||||
- Kubernetes [cluster federation design doc](https://github.com/kubernetes/kubernetes/blob/master/docs/design/federation-phase-1.md)
|
||||
- Kubernetes [blog post on multi zone clusters](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-kubernetes-new-multi-zone-clusters-aka-ubernetes-lite/)
|
||||
- Kubernetes [blog post on multi zone clusters](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-Kubernetes-new-multi-zone-clusters-a.k.a-Ubernetes-Lite)
|
||||
- Kubernetes [federated services design doc](https://github.com/kubernetes/kubernetes/blob/master/docs/design/federated-services.md)
|
||||
|
||||
|
||||
|
||||
@@ -4,13 +4,13 @@ date: 2016-07-11
|
||||
slug: minikube-easily-run-kubernetes-locally
|
||||
url: /blog/2016/07/Minikube-Easily-Run-Kubernetes-Locally
|
||||
---
|
||||
_Editor's note: This is the first post in a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3 _
|
||||
_Editor's note: This is the first post in a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3 _
|
||||
|
||||
While Kubernetes is one of the best tools for managing containerized applications available today, and has been production-ready for over a year, Kubernetes has been missing a great local development platform.
|
||||
|
||||
For the past several months, several of us from the Kubernetes community have been working to fix this in the [Minikube](http://github.com/kubernetes/minikube) repository on GitHub. Our goal is to build an easy-to-use, high-fidelity Kubernetes distribution that can be run locally on Mac, Linux and Windows workstations and laptops with a single command.
|
||||
|
||||
Thanks to lots of help from members of the community, we're proud to announce the official release of Minikube. This release comes with support for [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), new commands to make interacting with your local cluster easier and experimental drivers for xhyve (on macOS) and KVM (on Linux).
|
||||
Thanks to lots of help from members of the community, we're proud to announce the official release of Minikube. This release comes with support for [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), new commands to make interacting with your local cluster easier and experimental drivers for xhyve (on macOS) and KVM (on Linux).
|
||||
|
||||
**Using Minikube**
|
||||
|
||||
|
||||
@@ -4,9 +4,9 @@ date: 2016-07-11
|
||||
slug: rktnetes-brings-rkt-container-engine-to-kubernetes
|
||||
url: /blog/2016/07/Rktnetes-Brings-Rkt-Container-Engine-To-Kubernetes
|
||||
---
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3 _
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3 _
|
||||
|
||||
As part of [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), we’re happy to report that our work to bring interchangeable container engines to Kubernetes is bearing early fruit. What we affectionately call “rktnetes” is included in the version 1.3 Kubernetes release, and is ready for development use. rktnetes integrates support for [CoreOS rkt](https://coreos.com/rkt/) into Kubernetes as the container runtime on cluster nodes, and is now part of the mainline Kubernetes source code. Today it’s easier than ever for developers and ops pros with container portability in mind to try out running Kubernetes with a different container engine.
|
||||
As part of [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), we’re happy to report that our work to bring interchangeable container engines to Kubernetes is bearing early fruit. What we affectionately call “rktnetes” is included in the version 1.3 Kubernetes release, and is ready for development use. rktnetes integrates support for [CoreOS rkt](https://coreos.com/rkt/) into Kubernetes as the container runtime on cluster nodes, and is now part of the mainline Kubernetes source code. Today it’s easier than ever for developers and ops pros with container portability in mind to try out running Kubernetes with a different container engine.
|
||||
|
||||
"We find CoreOS’s rkt a compelling container engine in Kubernetes because of how rkt is composed with the underlying systemd,” said Mark Petrovic, senior MTS and architect at Xoom, a PayPal service. “The rkt runtime assumes only the responsibility it needs to, then delegates to other system services where appropriate. This separation of concerns is important to us.”
|
||||
|
||||
|
||||
@@ -5,13 +5,13 @@ slug: thousand-instances-of-cassandra-using-kubernetes-pet-set
|
||||
url: /blog/2016/07/Thousand-Instances-Of-Cassandra-Using-Kubernetes-Pet-Set
|
||||
---
|
||||
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_
|
||||
|
||||
|
||||
## Running The Greek Pet Monster Races
|
||||
|
||||
|
||||
For the [Kubernetes 1.3 launch](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), we wanted to put the new Pet Set through its paces. By testing a thousand instances of [Cassandra](https://cassandra.apache.org/), we could make sure that Kubernetes 1.3 was production ready. Read on for how we adapted Cassandra to Kubernetes, and had our largest deployment ever.
|
||||
For the [Kubernetes 1.3 launch](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), we wanted to put the new Pet Set through its paces. By testing a thousand instances of [Cassandra](https://cassandra.apache.org/), we could make sure that Kubernetes 1.3 was production ready. Read on for how we adapted Cassandra to Kubernetes, and had our largest deployment ever.
|
||||
|
||||
It’s fairly straightforward to use containers with basic stateful applications today. Using a persistent volume, you can mount a disk in a pod, and ensure that your data lasts beyond the life of your pod. However, with deployments of distributed stateful applications, things can become more tricky. With Kubernetes 1.3, the new [Pet Set](/docs/user-guide/petset/) component makes everything much easier. To test this new feature out at scale, we decided to host the Greek Pet Monster Races! We raced Centaurs and other Ancient Greek Monsters over hundreds of thousands of races across multiple availability zones.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ date: 2016-07-07
|
||||
slug: update-on-kubernetes-for-windows-server-containers
|
||||
url: /blog/2016/07/Update-On-Kubernetes-For-Windows-Server-Containers
|
||||
---
|
||||
We are proud to announce that with the [release of version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), Kubernetes now supports 2000-node clusters with even better end-to-end pod startup time. The latency of our API calls are within our one-second [Service Level Objective (SLO)](https://en.wikipedia.org/wiki/Service_level_objective) and most of them are even an order of magnitude better than that. It is possible to run larger deployments than a 2,000 node cluster, but performance may be degraded and it may not meet our strict SLO.
|
||||
We are proud to announce that with the [release of version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), Kubernetes now supports 2000-node clusters with even better end-to-end pod startup time. The latency of our API calls are within our one-second [Service Level Objective (SLO)](https://en.wikipedia.org/wiki/Service_level_objective) and most of them are even an order of magnitude better than that. It is possible to run larger deployments than a 2,000 node cluster, but performance may be degraded and it may not meet our strict SLO.
|
||||
|
||||
In this blog post we discuss the detailed performance results from Kubernetes 1.3 and what changes we made from version 1.2 to achieve these results. We also describe Kubemark, a performance testing tool that we’ve integrated into our continuous testing framework to detect performance and scalability regressions.
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ url: /blog/2016/07/happy-k8sbday-1
|
||||
---
|
||||
Last year at OSCON, I got to reconnect with a bunch of friends and see what they have been working on. That turned out to be the [Kubernetes 1.0 launch event](https://www.youtube.com/playlist?list=PL69nYSiGNLP0Ljwa9J98xUd6UlM604Y-l). Even that day, it was clear the project was supported by a broad community -- a group that showed an ambitious vision for distributed computing.
|
||||
|
||||
Today, on the first anniversary of the Kubernetes 1.0 launch, it’s amazing to see what a community of dedicated individuals can do. Kubernauts have collectively put in [237 person years of coding effort](https://www.openhub.net/p/kubernetes) since launch to bring forward our most recent [release 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). However the community is much more than simply coding effort. It is made up of people -- individuals that have given their expertise and energy to make this project flourish. With more than 830 diverse contributors, from independents to the largest companies in the world, it’s their work that makes Kubernetes stand out. Here are stories from a couple early contributors reflecting back on the project:
|
||||
Today, on the first anniversary of the Kubernetes 1.0 launch, it’s amazing to see what a community of dedicated individuals can do. Kubernauts have collectively put in [237 person years of coding effort](https://www.openhub.net/p/kubernetes) since launch to bring forward our most recent [release 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). However the community is much more than simply coding effort. It is made up of people -- individuals that have given their expertise and energy to make this project flourish. With more than 830 diverse contributors, from independents to the largest companies in the world, it’s their work that makes Kubernetes stand out. Here are stories from a couple early contributors reflecting back on the project:
|
||||
|
||||
|
||||
- [Sam Ghods](https://www.box.com/blog/kubernetes-box-microservices-maximum-velocity/), services architect and co-founder at Box
|
||||
|
||||
@@ -14,7 +14,7 @@ Google spent over ten years developing, applying and refining the principles of
|
||||
- Dynamically scheduled, for increased infrastructure efficiency and decreased operational overhead; and
|
||||
- Microservices-based. Loosely coupled components significantly increase the overall agility, resilience and maintainability of applications.
|
||||
|
||||
These principles have enabled us to build the largest, most efficient, most powerful cloud infrastructure in the world, which anyone can access via [Google Cloud Platform](http://cloud.google.com/). They are the same principles responsible for the recent surge in popularity of Linux containers. Two years ago, we open-sourced Kubernetes to spur adoption of containers and scalable, microservices-based applications, and the recently released [Kubernetes version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/) introduces a number of features to bridge enterprise and cloud native workloads. We expect that adoption of cloud-native principles will drive the same benefits within the OpenStack community, as well as smoothing the path between OpenStack and the public cloud providers that embrace them.
|
||||
These principles have enabled us to build the largest, most efficient, most powerful cloud infrastructure in the world, which anyone can access via [Google Cloud Platform](http://cloud.google.com/). They are the same principles responsible for the recent surge in popularity of Linux containers. Two years ago, we open-sourced Kubernetes to spur adoption of containers and scalable, microservices-based applications, and the recently released [Kubernetes version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads) introduces a number of features to bridge enterprise and cloud native workloads. We expect that adoption of cloud-native principles will drive the same benefits within the OpenStack community, as well as smoothing the path between OpenStack and the public cloud providers that embrace them.
|
||||
|
||||
**Making OpenStack better**
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ url: /blog/2016/07/stateful-applications-in-containers-kubernetes
|
||||
|
||||
_Editor's note: today’s guest post is from Mark Balch, VP of Products at Diamanti, who’ll share more about the contributions they’ve made to Kubernetes._
|
||||
|
||||
Congratulations to the Kubernetes community on another [value-packed release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). A focus on stateful applications and federated clusters are two reasons why I’m so excited about 1.3. Kubernetes support for stateful apps such as Cassandra, Kafka, and MongoDB is critical. Important services rely on databases, key value stores, message queues, and more. Additionally, relying on one data center or container cluster simply won’t work as apps grow to serve millions of users around the world. Cluster federation allows users to deploy apps across multiple clusters and data centers for scale and resiliency.
|
||||
Congratulations to the Kubernetes community on another [value-packed release](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). A focus on stateful applications and federated clusters are two reasons why I’m so excited about 1.3. Kubernetes support for stateful apps such as Cassandra, Kafka, and MongoDB is critical. Important services rely on databases, key value stores, message queues, and more. Additionally, relying on one data center or container cluster simply won’t work as apps grow to serve millions of users around the world. Cluster federation allows users to deploy apps across multiple clusters and data centers for scale and resiliency.
|
||||
|
||||
You may have [heard me say before](https://www.diamanti.com/blog/the-next-great-application-platform/) that containers are the next great application platform. Diamanti is accelerating container adoption for stateful apps in production - where performance and ease of deployment really matter.
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: " Kubernetes 1.4: Making it easy to run on Kubernetes anywhere "
|
||||
date: 2016-09-26
|
||||
slug: kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere
|
||||
url: /blog/2016/09/Kubernetes-1-4-Making-It-Easy-To-Run-On-Kuberentes-Anywhere
|
||||
url: /blog/2016/09/Kubernetes-1.4-Making-It-Easy-To-Run-On-Kuberentes-Anywhere
|
||||
---
|
||||
Today we’re happy to announce the release of Kubernetes 1.4.
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ slug: dynamic-provisioning-and-storage-in-kubernetes
|
||||
url: /blog/2016/10/Dynamic-Provisioning-And-Storage-In-Kubernetes
|
||||
---
|
||||
|
||||
Storage is a critical part of running containers, and Kubernetes offers some powerful primitives for managing it. Dynamic volume provisioning, a feature unique to Kubernetes, allows storage volumes to be created on-demand. Without dynamic provisioning, cluster administrators have to manually make calls to their cloud or storage provider to create new storage volumes, and then create PersistentVolume objects to represent them in Kubernetes. The dynamic provisioning feature eliminates the need for cluster administrators to pre-provision storage. Instead, it automatically provisions storage when it is requested by users. This feature was introduced as alpha in Kubernetes 1.2, and has been improved and promoted to beta in the [latest release, 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/). This release makes dynamic provisioning far more flexible and useful.
|
||||
Storage is a critical part of running containers, and Kubernetes offers some powerful primitives for managing it. Dynamic volume provisioning, a feature unique to Kubernetes, allows storage volumes to be created on-demand. Without dynamic provisioning, cluster administrators have to manually make calls to their cloud or storage provider to create new storage volumes, and then create PersistentVolume objects to represent them in Kubernetes. The dynamic provisioning feature eliminates the need for cluster administrators to pre-provision storage. Instead, it automatically provisions storage when it is requested by users. This feature was introduced as alpha in Kubernetes 1.2, and has been improved and promoted to beta in the [latest release, 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere). This release makes dynamic provisioning far more flexible and useful.
|
||||
|
||||
**What’s New?**
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ _Editor's note: Today’s post is by Allan Naim, Product Manager, and Quinton Ho
|
||||
|
||||
In Kubernetes 1.3, we announced Kubernetes Cluster Federation and introduced the concept of Cross Cluster Service Discovery, enabling developers to deploy a service that was sharded across a federation of clusters spanning different zones, regions or cloud providers. This enables developers to achieve higher availability for their applications, without sacrificing quality of service, as detailed in our [previous](https://kubernetes.io/blog/2016/07/cross-cluster-services) blog post.
|
||||
|
||||
In the latest release, [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/), we've extended Cluster Federation to support Replica Sets, Secrets, Namespaces and Ingress objects. This means that you no longer need to deploy and manage these objects individually in each of your federated clusters. Just create them once in the federation, and have its built-in controllers automatically handle that for you.
|
||||
In the latest release, [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere), we've extended Cluster Federation to support Replica Sets, Secrets, Namespaces and Ingress objects. This means that you no longer need to deploy and manage these objects individually in each of your federated clusters. Just create them once in the federation, and have its built-in controllers automatically handle that for you.
|
||||
|
||||
[**Federated Replica Sets**](/docs/user-guide/federation/replicasets/) leverage the same configuration as non-federated Kubernetes Replica Sets and automatically distribute Pods across one or more federated clusters. By default, replicas are evenly distributed across all clusters, but for cases where that is not the desired behavior, we've introduced Replica Set preferences, which allow replicas to be distributed across only some clusters, or in non-equal proportions ([define annotations](https://github.com/kubernetes/kubernetes/blob/master/federation/apis/federation/types.go#L114)).
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ So what do you do when there are too many places for things to be found?
|
||||
|
||||
|
||||
|
||||
In this case, we’re not creating Yet Another Place for Applications, rather promoting an existing one as the canonical location. As part of the Special Interest Group Apps ([SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps)) work for the [Kubernetes 1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/), we began to provide a home for these Kubernetes deployable applications that provides continuous releases of well documented and user friendly packages. These packages are being created as Helm [**Charts**](https://github.com/kubernetes/helm/blob/master/docs/charts.md) and can be installed using the Helm tool. **[Helm](https://github.com/kubernetes/helm)** allows users to easily templatize their Kubernetes manifests and provide a set of configuration parameters that allows users to customize their deployment.
|
||||
In this case, we’re not creating Yet Another Place for Applications, rather promoting an existing one as the canonical location. As part of the Special Interest Group Apps ([SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps)) work for the [Kubernetes 1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere), we began to provide a home for these Kubernetes deployable applications that provides continuous releases of well documented and user friendly packages. These packages are being created as Helm [**Charts**](https://github.com/kubernetes/helm/blob/master/docs/charts.md) and can be installed using the Helm tool. **[Helm](https://github.com/kubernetes/helm)** allows users to easily templatize their Kubernetes manifests and provide a set of configuration parameters that allows users to customize their deployment.
|
||||
|
||||
**Helm is the package manager** (analogous to yum and apt) and **Charts are packages** (analogous to debs and rpms). The home for these Charts is the [Kubernetes Charts repository](https://github.com/kubernetes/charts) which provides continuous integration for pull requests, as well as automated releases of Charts in the master branch.
|
||||
|
||||
@@ -34,11 +34,11 @@ The following applications are now available:
|
||||
|[Drupal](https://github.com/kubernetes/charts/tree/master/stable/drupal) | [Consul](https://github.com/kubernetes/charts/tree/master/incubator/consul) |
|
||||
|[Jenkins](https://github.com/kubernetes/charts/tree/master/stable/jenkins)|[Elasticsearch](https://github.com/kubernetes/charts/tree/master/incubator/elasticsearch) |
|
||||
| [MariaDB](https://github.com/kubernetes/charts/tree/master/stable/mariadb) | [etcd](https://github.com/kubernetes/charts/tree/master/incubator/etcd) |
|
||||
| [MySQL](https://github.com/kubernetes/charts/tree/master/stable/mysql) | [Grafana](https://github.com/helm/charts/tree/master/stable/grafana) |
|
||||
| [Redmine](https://github.com/kubernetes/charts/tree/master/stable/redmine)|[MongoDB](https://github.com/helm/charts/tree/master/stable/mongodb)|
|
||||
| [MySQL](https://github.com/kubernetes/charts/tree/master/stable/mysql) | [Grafana](https://github.com/kubernetes/charts/tree/master/incubator/grafana) |
|
||||
| [Redmine](https://github.com/kubernetes/charts/tree/master/stable/redmine)|[MongoDB](https://github.com/kubernetes/charts/tree/master/incubator/mongodb)|
|
||||
| [Wordpress](https://github.com/kubernetes/charts/tree/master/stable/wordpress)|[Patroni](https://github.com/kubernetes/charts/tree/master/incubator/patroni) |
|
||||
||[Prometheus](https://github.com/helm/charts/tree/master/stable/prometheus)|
|
||||
| | [Spark](https://github.com/helm/charts/tree/master/stable/spark)|
|
||||
||[Prometheus](https://github.com/kubernetes/charts/tree/master/incubator/prometheus)|
|
||||
| | [Spark](https://github.com/kubernetes/charts/tree/master/incubator/spark)|
|
||||
| | [ZooKeeper](https://github.com/kubernetes/charts/tree/master/incubator/zookeeper) |
|
||||
|
||||
|
||||
@@ -56,16 +56,16 @@ The following applications are now available:
|
||||
**Example workflow for a Chart user**
|
||||
|
||||
|
||||
1. 1.[Install Helm](https://helm.sh/docs/intro/quickstart/#install-helm)
|
||||
2. 2.[Initialize Helm](https://helm.sh/docs/intro/quickstart/#install-an-example-chart)
|
||||
3. 3.[Search for a chart](https://helm.sh/docs/intro/using_helm/#helm-search-finding-charts)
|
||||
1. 1.[Install Helm](https://github.com/kubernetes/helm/blob/master/docs/quickstart.md#install-helm)
|
||||
2. 2.[Initialize Helm](https://github.com/kubernetes/helm/blob/master/docs/quickstart.md#install-an-example-chart)
|
||||
3. 3.[Search for a chart](https://github.com/kubernetes/helm/blob/master/docs/using_helm.md#helm-search-finding-charts)
|
||||
|
||||
```
|
||||
$ helm search
|
||||
NAME VERSION DESCRIPTION stable/drupal 0.3.1 One of the most versatile open source content m...stable/jenkins 0.1.0 A Jenkins Helm chart for Kubernetes. stable/mariadb 0.4.0 Chart for MariaDB stable/mysql 0.1.0 Chart for MySQL stable/redmine 0.3.1 A flexible project management web application. stable/wordpress 0.3.0 Web publishing platform for building blogs and ...
|
||||
```
|
||||
|
||||
4. 4.[Install the chart](https://helm.sh/docs/intro/using_helm/#helm-install-installing-a-package)
|
||||
4. 4.[Install the chart](https://github.com/kubernetes/helm/blob/master/docs/using_helm.md#helm-install-installing-a-package)
|
||||
|
||||
```
|
||||
$ helm install stable/jenkins
|
||||
|
||||
@@ -2,9 +2,9 @@
|
||||
title: " How we improved Kubernetes Dashboard UI in 1.4 for your production needs "
|
||||
date: 2016-10-03
|
||||
slug: production-kubernetes-dashboard-ui-1.4-improvements_3
|
||||
url: /blog/2016/10/Production-Kubernetes-Dashboard-UI-1-4-improvements_3
|
||||
url: /blog/2016/10/Production-Kubernetes-Dashboard-UI-1.4-improvements_3
|
||||
---
|
||||
With the release of [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/) last week, Dashboard – the official web UI for Kubernetes – has a number of exciting updates and improvements of its own. The past three months have been busy ones for the Dashboard team, and we’re excited to share the resulting features of that effort here. If you’re not familiar with Dashboard, the [GitHub repo](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a great place to get started.
|
||||
With the release of [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere) last week, Dashboard – the official web UI for Kubernetes – has a number of exciting updates and improvements of its own. The past three months have been busy ones for the Dashboard team, and we’re excited to share the resulting features of that effort here. If you’re not familiar with Dashboard, the [GitHub repo](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a great place to get started.
|
||||
|
||||
A quick recap before unwrapping our shiny new features: Dashboard was initially released March 2016. One of the focuses for Dashboard throughout its lifetime has been the onboarding experience; it’s a less intimidating way for Kubernetes newcomers to get started, and by showing multiple resources at once, it provides contextualization lacking in [kubectl](/docs/user-guide/kubectl-overview/) (the CLI). After that initial release though, the product team realized that fine-tuning for a beginner audience was getting ahead of ourselves: there were still fundamental product requirements that Dashboard needed to satisfy in order to have a productive UX to onboard new users too. That became our mission for this release: closing the gap between Dashboard and kubectl by showing more resources, leveraging a web UI’s strengths in monitoring and troubleshooting, and architecting this all in a user friendly way.
|
||||
|
||||
|
||||
@@ -4,29 +4,29 @@ date: 2016-11-07
|
||||
slug: bringing-kubernetes-support-to-azure
|
||||
url: /blog/2016/11/Bringing-Kubernetes-Support-To-Azure
|
||||
---
|
||||
_Editor's note: Today’s post is by Brendan Burns, Partner Architect, at Microsoft & Kubernetes co-founder talking about bringing Kubernetes to Azure Container Service._
|
||||
|
||||
With more than a thousand people coming to [KubeCon](http://events.linuxfoundation.org/events/kubecon) in my hometown of Seattle, nearly three years after I helped start the Kubernetes project, it’s amazing and humbling to see what a small group of people and a radical idea have become after three years of hard work from a large and growing community. In July of 2014, scarcely a month after Kubernetes became publicly available, Microsoft announced its initial support for Azure. The release of [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/), brought support for native Microsoft networking, [load-balancer](https://github.com/kubernetes/kubernetes/pull/28821) and [disk integration](https://github.com/kubernetes/kubernetes/pull/29836).
|
||||
|
||||
Today, Microsoft [announced](https://azure.microsoft.com/en-us/blog/azure-container-service-the-cloud-s-most-open-option-for-containers/) the next step in Kubernetes on Azure: the introduction of Kubernetes as a supported orchestrator in Azure Container Service (ACS). It’s been really exciting for me to join the ACS team and help build this new addition. The integration of Kubernetes into ACS means that with a few clicks in the Azure portal, or by running a single command in the new python-based Azure command line tool, you will be able to create a fully functional Kubernetes cluster that is integrated with the rest of your Azure resources.
|
||||
|
||||
Kubernetes is available in public preview in Azure Container Service today. Community participation has always been an important part of the Kubernetes experience. Over the next few months, I hope you’ll join us and provide your feedback on the experience as we bring it to general availability.
|
||||
|
||||
In the spirit of community, we are also excited to announce a new open source project: [ACS Engine](https://github.com/azure/acs-engine). The goal of ACS Engine is to provide an open, community driven location to develop and share best practices for orchestrating containers on Azure. All of our knowledge of running containers in Azure has been captured in that repository, and we look forward to improving and extending it as we move forward with the community. Going forward, the templates in ACS Engine will be the basis for clusters deployed via the ACS API, and thus community driven improvements, features and more will have a natural path into the Azure Container Service. We’re excited to invite you to join us in improving ACS. Prior to the creation of ACS Engine, customers with unique requirements not supported by the ACS API needed to maintain variations on our templates. While these differences start small, they grew larger over time as the mainline template was improved and users also iterated their templates. These differences and drift really impact the ability for users to collaborate, since their templates are all different. Without the ability to share and collaborate, it’s difficult to form a community since every user is siloed in their own variant.
|
||||
|
||||
To solve this problem, the core of ACS Engine is a template processor, built in Go, that enables you to dynamically combine different pieces of configuration together to form a final template that can be used to build up your cluster. Thus, each user can mix and match the pieces build the final container cluster that suits their needs. At the same time, each piece can be built and maintained collaboratively by the community. We’ve been beta testing this approach with some customers and the feedback we’ve gotten so far has been really positive.
|
||||
|
||||
Beyond services to help you run containers on Azure, I think it’s incredibly important to improve the experience of developing and deploying containerized applications to Kubernetes. To that end, I’ve been doing a bunch of work lately to build a Kubernetes extension for the really excellent, open source, [Visual Studio Code](https://code.visualstudio.com/). The Kubernetes extension enables you to quickly deploy JSON or YAML files you are editing onto a Kubernetes cluster. Additionally, it enables you to import existing Kubernetes objects into Code for easy editing. Finally, it enables synchronization between your running containers and the source code that you are developing for easy debugging of issues you are facing in production.
|
||||
|
||||
But really, a demo is worth a thousand words, so please have a look at this [video](https://www.youtube.com/watch?v=nhY9XdzNbbY):
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Of course, like everything else in Kubernetes it’s released as open source, and I look forward to working on it further with the community. Thanks again, I look forward to seeing everyone at the OpenShift Gathering today, as well as at the Microsoft Azure booth during KubeCon tomorrow and Wednesday. Welcome to Seattle!
|
||||
_Editor's note: Today’s post is by Brendan Burns, Partner Architect, at Microsoft & Kubernetes co-founder talking about bringing Kubernetes to Azure Container Service._
|
||||
|
||||
With more than a thousand people coming to [KubeCon](http://events.linuxfoundation.org/events/kubecon) in my hometown of Seattle, nearly three years after I helped start the Kubernetes project, it’s amazing and humbling to see what a small group of people and a radical idea have become after three years of hard work from a large and growing community. In July of 2014, scarcely a month after Kubernetes became publicly available, Microsoft announced its initial support for Azure. The release of [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere), brought support for native Microsoft networking, [load-balancer](https://github.com/kubernetes/kubernetes/pull/28821) and [disk integration](https://github.com/kubernetes/kubernetes/pull/29836).
|
||||
|
||||
Today, Microsoft [announced](https://azure.microsoft.com/en-us/blog/azure-container-service-the-cloud-s-most-open-option-for-containers/) the next step in Kubernetes on Azure: the introduction of Kubernetes as a supported orchestrator in Azure Container Service (ACS). It’s been really exciting for me to join the ACS team and help build this new addition. The integration of Kubernetes into ACS means that with a few clicks in the Azure portal, or by running a single command in the new python-based Azure command line tool, you will be able to create a fully functional Kubernetes cluster that is integrated with the rest of your Azure resources.
|
||||
|
||||
Kubernetes is available in public preview in Azure Container Service today. Community participation has always been an important part of the Kubernetes experience. Over the next few months, I hope you’ll join us and provide your feedback on the experience as we bring it to general availability.
|
||||
|
||||
In the spirit of community, we are also excited to announce a new open source project: [ACS Engine](https://github.com/azure/acs-engine). The goal of ACS Engine is to provide an open, community driven location to develop and share best practices for orchestrating containers on Azure. All of our knowledge of running containers in Azure has been captured in that repository, and we look forward to improving and extending it as we move forward with the community. Going forward, the templates in ACS Engine will be the basis for clusters deployed via the ACS API, and thus community driven improvements, features and more will have a natural path into the Azure Container Service. We’re excited to invite you to join us in improving ACS. Prior to the creation of ACS Engine, customers with unique requirements not supported by the ACS API needed to maintain variations on our templates. While these differences start small, they grew larger over time as the mainline template was improved and users also iterated their templates. These differences and drift really impact the ability for users to collaborate, since their templates are all different. Without the ability to share and collaborate, it’s difficult to form a community since every user is siloed in their own variant.
|
||||
|
||||
To solve this problem, the core of ACS Engine is a template processor, built in Go, that enables you to dynamically combine different pieces of configuration together to form a final template that can be used to build up your cluster. Thus, each user can mix and match the pieces build the final container cluster that suits their needs. At the same time, each piece can be built and maintained collaboratively by the community. We’ve been beta testing this approach with some customers and the feedback we’ve gotten so far has been really positive.
|
||||
|
||||
Beyond services to help you run containers on Azure, I think it’s incredibly important to improve the experience of developing and deploying containerized applications to Kubernetes. To that end, I’ve been doing a bunch of work lately to build a Kubernetes extension for the really excellent, open source, [Visual Studio Code](https://code.visualstudio.com/). The Kubernetes extension enables you to quickly deploy JSON or YAML files you are editing onto a Kubernetes cluster. Additionally, it enables you to import existing Kubernetes objects into Code for easy editing. Finally, it enables synchronization between your running containers and the source code that you are developing for easy debugging of issues you are facing in production.
|
||||
|
||||
But really, a demo is worth a thousand words, so please have a look at this [video](https://www.youtube.com/watch?v=nhY9XdzNbbY):
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Of course, like everything else in Kubernetes it’s released as open source, and I look forward to working on it further with the community. Thanks again, I look forward to seeing everyone at the OpenShift Gathering today, as well as at the Microsoft Azure booth during KubeCon tomorrow and Wednesday. Welcome to Seattle!
|
||||
|
||||
|
||||
|
||||
- [Download](http://get.k8s.io/) Kubernetes
|
||||
- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
title: " Cluster Federation in Kubernetes 1.5 "
|
||||
date: 2016-12-22
|
||||
slug: cluster-federation-in-kubernetes-1.5
|
||||
url: /blog/2016/12/Cluster-Federation-In-Kubernetes-1-5
|
||||
url: /blog/2016/12/Cluster-Federation-In-Kubernetes-1.5
|
||||
---
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1-5/) on what's new in Kubernetes 1.5_
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1.5) on what's new in Kubernetes 1.5_
|
||||
|
||||
In the latest [Kubernetes 1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/), you’ll notice that support for Cluster Federation is maturing. That functionality was introduced in Kubernetes 1.3, and the 1.5 release includes a number of new features, including an easier setup experience and a step closer to supporting all Kubernetes API objects.
|
||||
In the latest [Kubernetes 1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads), you’ll notice that support for Cluster Federation is maturing. That functionality was introduced in Kubernetes 1.3, and the 1.5 release includes a number of new features, including an easier setup experience and a step closer to supporting all Kubernetes API objects.
|
||||
|
||||
A new command line tool called ‘**[kubefed](/docs/admin/federation/kubefed/)**’ was introduced to make getting started with Cluster Federation much simpler. Also, alpha level support was added for Federated DaemonSets, Deployments and ConfigMaps. In summary:
|
||||
|
||||
|
||||
@@ -4,14 +4,14 @@ date: 2016-12-19
|
||||
slug: container-runtime-interface-cri-in-kubernetes
|
||||
url: /blog/2016/12/Container-Runtime-Interface-Cri-In-Kubernetes
|
||||
---
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1-5/) on what's new in Kubernetes 1.5_
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1.5) on what's new in Kubernetes 1.5_
|
||||
|
||||
|
||||
At the lowest layers of a Kubernetes node is the software that, among other things, starts and stops containers. We call this the “Container Runtime”. The most widely known container runtime is Docker, but it is not alone in this space. In fact, the container runtime space has been rapidly evolving. As part of the effort to make Kubernetes more extensible, we've been working on a new plugin API for container runtimes in Kubernetes, called "CRI".
|
||||
|
||||
**What is the CRI and why does Kubernetes need it?**
|
||||
|
||||
Each container runtime has it own strengths, and many users have asked for Kubernetes to support more runtimes. In the Kubernetes 1.5 release, we are proud to introduce the [Container Runtime Interface](https://github.com/kubernetes/kubernetes/blob/242a97307b34076d5d8f5bbeb154fa4d97c9ef1d/docs/devel/container-runtime-interface.md) (CRI) -- a plugin interface which enables kubelet to use a wide variety of container runtimes, without the need to recompile. CRI consists of a [protocol buffers](https://developers.google.com/protocol-buffers/) and [gRPC API](http://www.grpc.io/), and [libraries](https://github.com/kubernetes/kubernetes/tree/release-1.5/pkg/kubelet/server/streaming), with additional specifications and tools under active development. CRI is being released as Alpha in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads).
|
||||
Each container runtime has it own strengths, and many users have asked for Kubernetes to support more runtimes. In the Kubernetes 1.5 release, we are proud to introduce the [Container Runtime Interface](https://github.com/kubernetes/kubernetes/blob/242a97307b34076d5d8f5bbeb154fa4d97c9ef1d/docs/devel/container-runtime-interface.md) (CRI) -- a plugin interface which enables kubelet to use a wide variety of container runtimes, without the need to recompile. CRI consists of a [protocol buffers](https://developers.google.com/protocol-buffers/) and [gRPC API](http://www.grpc.io/), and [libraries](https://github.com/kubernetes/kubernetes/tree/release-1.5/pkg/kubelet/server/streaming), with additional specifications and tools under active development. CRI is being released as Alpha in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads).
|
||||
|
||||
Supporting interchangeable container runtimes is not a new concept in Kubernetes. In the 1.3 release, we announced the [rktnetes](https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-Kubernetes) project to enable [rkt container engine](https://github.com/coreos/rkt) as an alternative to the Docker container runtime. However, both Docker and rkt were integrated directly and deeply into the kubelet source code through an internal and volatile interface. Such an integration process requires a deep understanding of Kubelet internals and incurs significant maintenance overhead to the Kubernetes community. These factors form high barriers to entry for nascent container runtimes. By providing a clearly-defined abstraction layer, we eliminate the barriers and allow developers to focus on building their container runtimes. This is a small, yet important step towards truly enabling pluggable container runtimes and building a healthier ecosystem.
|
||||
|
||||
@@ -90,7 +90,7 @@ Another potential issue with the kubelet implementation today is that kubelet ha
|
||||
|
||||
|
||||
|
||||
There are many other aspects of CRI that are not covered in this blog post. Please see the list of [design docs and proposals](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md#design-docs-and-proposals) for all the details.
|
||||
There are many other aspects of CRI that are not covered in this blog post. Please see the list of [design docs and proposals](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md#design-docs-and-proposals) for all the details.
|
||||
|
||||
|
||||
|
||||
@@ -100,7 +100,7 @@ Although CRI is still in its early stages, there are already several projects un
|
||||
|
||||
|
||||
|
||||
- [cri-o](https://cri-o.io/): OCI conformant runtimes.
|
||||
- [cri-o](https://github.com/kubernetes-incubator/cri-o): OCI conformant runtimes.
|
||||
- [rktlet](https://github.com/kubernetes-incubator/rktlet): the rkt container runtime.
|
||||
- [frakti](https://github.com/kubernetes/frakti): hypervisor-based container runtimes.
|
||||
- [docker CRI shim](https://github.com/kubernetes/kubernetes/tree/release-1.5/pkg/kubelet/dockershim).
|
||||
@@ -112,7 +112,7 @@ If you are interested in trying these alternative runtimes, you can follow the i
|
||||
|
||||
|
||||
|
||||
For developers interested in integrating a new container runtime, please see the [developer guide](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) for the known limitations and issues of the API. We are actively incorporating feedback from early developers to improve the API. Developers should expect occasional API breaking changes (it is Alpha, after all).
|
||||
For developers interested in integrating a new container runtime, please see the [developer guide](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md) for the known limitations and issues of the API. We are actively incorporating feedback from early developers to improve the API. Developers should expect occasional API breaking changes (it is Alpha, after all).
|
||||
|
||||
|
||||
|
||||
@@ -124,7 +124,7 @@ Kubelet does not yet use CRI by default, but we are actively working on making t
|
||||
|
||||
|
||||
|
||||
Besides a few [missing features](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md#docker-cri-integration-known-issues), the new integration has consistently passed the main end-to-end tests. We plan to expand the test coverage soon and would like to encourage the community to report any issues to help with the transition.
|
||||
Besides a few [missing features](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md#docker-cri-integration-known-issues), the new integration has consistently passed the main end-to-end tests. We plan to expand the test coverage soon and would like to encourage the community to report any issues to help with the transition.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,9 +2,9 @@
|
||||
title: " Five Days of Kubernetes 1.5 "
|
||||
date: 2016-12-19
|
||||
slug: five-days-of-kubernetes-1.5
|
||||
url: /blog/2016/12/Five-Days-Of-Kubernetes-1-5
|
||||
url: /blog/2016/12/Five-Days-Of-Kubernetes-1.5
|
||||
---
|
||||
With the help of our growing community of 1,000 contributors, we pushed some 5,000 commits to extend support for production workloads and deliver [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/). While many improvements and new features have been added, we selected few to highlight in a series of in-depths posts listed below.
|
||||
With the help of our growing community of 1,000 contributors, we pushed some 5,000 commits to extend support for production workloads and deliver [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads). While many improvements and new features have been added, we selected few to highlight in a series of in-depths posts listed below.
|
||||
|
||||
This progress is our commitment in continuing to make Kubernetes best way to manage your production workloads at scale.
|
||||
|
||||
@@ -13,7 +13,7 @@ This progress is our commitment in continuing to make Kubernetes best way to man
|
||||
| Day 1 | [Introducing Container Runtime Interface (CRI) in Kubernetes](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes) |
|
||||
| Day 2 | [StatefulSet: Run and Scale Stateful Applications Easily in Kubernetes](https://kubernetes.io/blog/2016/12/statefulset-run-scale-stateful-applications-in-kubernetes) |
|
||||
| Day 3 | [Windows Server Support Comes to Kubernetes](https://kubernetes.io/blog/2016/12/windows-server-support-kubernetes) |
|
||||
| Day 4 | [Cluster Federation in Kubernetes 1.5](https://kubernetes.io/blog/2016/12/cluster-federation-in-kubernetes-1-5/) |
|
||||
| Day 4 | [Cluster Federation in Kubernetes 1.5](https://kubernetes.io/blog/2016/12/cluster-federation-in-kubernetes-1.5) |
|
||||
| Day 5 | [Kubernetes supports OpenAPI](https://kubernetes.io/blog/2016/12/kubernetes-supports-openapi) |
|
||||
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: " Kubernetes 1.5: Supporting Production Workloads "
|
||||
date: 2016-12-13
|
||||
slug: kubernetes-1.5-supporting-production-workloads
|
||||
url: /blog/2016/12/Kubernetes-1-5-Supporting-Production-Workloads
|
||||
url: /blog/2016/12/Kubernetes-1.5-Supporting-Production-Workloads
|
||||
---
|
||||
|
||||
Today we’re announcing the release of Kubernetes 1.5. This release follows close on the heels of KubeCon/CloundNativeCon, where users gathered to share how they’re running their applications on Kubernetes. Many of you expressed interest in running stateful applications in containers with the eventual goal of running all applications on Kubernetes. If you have been waiting to try running a distributed database on Kubernetes, or for ways to guarantee application disruption SLOs for stateful and stateless apps, this release has solutions for you.
|
||||
@@ -54,11 +54,11 @@ The CNCF recently announced the [Kubernetes Managed Service Provider](https://ku
|
||||
**Community Velocity**
|
||||
In the past three months we’ve seen more than a hundred new contributors join the project with some 5,000 commits pushed, reaching new milestones by bringing the total for the core project to 1,000+ contributors and 40,000+ commits. This incredible momentum is only possible by having an open design, being open to new ideas, and empowering an open community to be welcoming to new and senior contributors alike. A big thanks goes out to the release team for 1.5 -- Saad Ali of Google, Davanum Srinivas of Mirantis, and Caleb Miles of CoreOS for their work bringing the 1.5 release to light.
|
||||
|
||||
Offline, the community can be found at one of the many Kubernetes related [meetups](https://www.meetup.com/topics/kubernetes/) around the world. The strength and scale of the community was visible in the crowded halls of CloudNativeCon/KubeCon Seattle (the recorded user talks are [here](https://www.youtube.com/playlist?list=PLj6h78yzYM2PqgIGU1Qmi8nY7dqn9PCr4)). The next C[loudNativeCon + KubeCon is in Berlin](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) March 29-30, 2017, be sure to get your ticket and [submit your talk](https://docs.google.com/a/google.com/forms/d/e/1FAIpQLSc0lPQhSuDusPXLKJDTcWrH3DbOuoQlTD0lB4IGUz6NAmcf2g/viewform) before the CFP deadline of Dec 16th.
|
||||
Offline, the community can be found at one of the many Kubernetes related [meetups](https://www.meetup.com/topics/kubernetes/) around the world. The strength and scale of the community was visible in the crowded halls of CloudNativeCon/KubeCon Seattle (the recorded user talks are [here](https://www.youtube.com/playlist?list=PLj6h78yzYM2PqgIGU1Qmi8nY7dqn9PCr4)). The next C[loudNativeCon + KubeCon is in Berlin](http://events.linuxfoundation.org/events/cloudnativecon-and-kubecon-europe) March 29-30, 2017, be sure to get your ticket and [submit your talk](https://docs.google.com/a/google.com/forms/d/e/1FAIpQLSc0lPQhSuDusPXLKJDTcWrH3DbOuoQlTD0lB4IGUz6NAmcf2g/viewform) before the CFP deadline of Dec 16th.
|
||||
|
||||
|
||||
|
||||
Ready to start contributing? Share your voice at our weekly [community meeting](https://kubernetes.io/community/).
|
||||
Ready to start contributing? Share your voice at our weekly [community meeting](https://github.com/kubernetes/community/blob/master/community/README.md).
|
||||
|
||||
|
||||
- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
|
||||
|
||||
@@ -4,11 +4,11 @@ date: 2016-12-23
|
||||
slug: kubernetes-supports-openapi
|
||||
url: /blog/2016/12/Kubernetes-Supports-Openapi
|
||||
---
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1-5/) on what's new in Kubernetes 1.5_
|
||||
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1.5) on what's new in Kubernetes 1.5_
|
||||
|
||||
[OpenAPI](https://www.openapis.org/) allows API providers to define their operations and models, and enables developers to automate their tools and generate their favorite language’s client to talk to that API server. Kubernetes has supported swagger 1.2 (older version of OpenAPI spec) for a while, but the spec was incomplete and invalid, making it hard to generate tools/clients based on it.
|
||||
|
||||
In Kubernetes 1.4, we introduced alpha support for the OpenAPI spec (formerly known as swagger 2.0 before it was donated to the [Open API Initiative](https://www.openapis.org/about)) by upgrading the current models and operations. Beginning in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/), the support for the OpenAPI spec has been completed by auto-generating the spec directly from Kubernetes source, which will keep the spec--and documentation--completely in sync with future changes in operations/models.
|
||||
In Kubernetes 1.4, we introduced alpha support for the OpenAPI spec (formerly known as swagger 2.0 before it was donated to the [Open API Initiative](https://www.openapis.org/about)) by upgrading the current models and operations. Beginning in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads), the support for the OpenAPI spec has been completed by auto-generating the spec directly from Kubernetes source, which will keep the spec--and documentation--completely in sync with future changes in operations/models.
|
||||
|
||||
The new spec enables us to have better API documentation and we have even introduced a supported [python client](https://github.com/kubernetes-incubator/client-python).
|
||||
|
||||
|
||||