Compare commits

..

16 Commits

Author SHA1 Message Date
Steve Perry 1274670dea Update URL for 1.7 docs. 2017-10-10 12:41:48 -07:00
Steve Perry 37e1b9819c Add 1.8 to version picker for 1.4 docs. (#5833) 2017-10-09 22:19:00 -07:00
Andrew Chen 95002f4314 Merge pull request #5270 from kubernetes/chenopis-1.4-patch
Make caret for version drop-down more visible in v1.4
2017-09-01 17:07:43 -07:00
Andrew Chen a5d01ae6b6 Make caret for version drop-down more visible in v1.4 2017-09-01 17:02:50 -07:00
Andrew Chen fd975899a6 Add deprecation warning to release-1.4 (#4756)
* Add Version Selector to v1.4

* upgrade to newer header

* change include_cached to include

* move head.html to correct location

* remove seo

* add footer-scripts.html

* turn on global nav

* fix docs nav link

* Add deprecation warning to release-1.4

* remove warning from index.html

* add newlines
2017-08-10 22:20:59 -07:00
Andrew Chen d00396ef79 Add Version Selector to v1.4 (#4746)
* Add Version Selector to v1.4

* upgrade to newer header

* change include_cached to include

* move head.html to correct location

* remove seo

* add footer-scripts.html

* turn on global nav

* fix docs nav link
2017-08-10 17:43:56 -07:00
Andrew Chen 68a6b91536 update githubbranch 2017-08-07 16:34:56 -07:00
Andrew Chen 157fc38669 use page variable instead of hardcoded master 2017-08-07 16:24:04 -07:00
Andrew Chen 748fcec13a update release version 2017-08-07 16:19:17 -07:00
Andrew Chen 7b662446b3 Merge pull request #4463 from kubernetes/release-1.4-patch
prevent bot indexing in v1.4 docs
2017-07-24 16:12:31 -07:00
Andrew Chen 377e7e2364 update .travis.yml 2017-07-24 16:07:48 -07:00
Andrew Chen 0bc73b8e9b prevent bot indexing 2017-07-24 15:52:12 -07:00
Andrew Chen 4e995f55a9 update to final snaphot 2017-07-24 15:04:08 -07:00
Mike Danese 571d2324db Merge pull request #1321 from lukemarsden/official-packages
Update kubeadm guide to use official stable deb and rpm repos
2016-09-27 08:07:30 -07:00
Luke Marsden 5524edba2a Use the official 1.4.0 image. 2016-09-27 15:58:01 +01:00
Luke Marsden cf14a29b53 Update kubeadm guide to use official stable deb and rpm repos. Thanks @mikedanese! 2016-09-27 15:51:32 +01:00
2900 changed files with 302858 additions and 457209 deletions
-8
View File
@@ -1,8 +0,0 @@
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> For 1.11 Features: set Milestone to 1.11 and Base Branch to release-1.11
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> NOTE: After opening the PR, please *un-check and re-check* the ["Allow edits from maintainers"](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/) box so that maintainers can work on your patch and speed up the review process. This is a temporary workaround to address a known issue with GitHub.>
>
> Please delete this note before submitting the pull request.
![Allow edits from maintainers checkbox](https://help.github.com/assets/images/help/pull_requests/allow-maintainers-to-make-edits-sidebar-checkbox.png)
+1 -25
View File
@@ -1,31 +1,7 @@
**/.DS_Store
**/desktop.ini
.jekyll-metadata
_site/**
.sass-cache/**
CNAME
.travis.yml
.idea/
.vscode/
# Vim ignore
# source: https://github.com/github/gitignore/blob/master/Global/Vim.gitignore
# swap
[._]*.s[a-v][a-z]
[._]*.sw[a-p]
[._]s[a-v][a-z]
[._]sw[a-p]
# session
Session.vim
# temporary
.netrwhist
*~
# auto-generated tag files
tags
kubernetes.github.io.iml
nohup.out
# Hugo output
public/
+11 -9
View File
@@ -1,22 +1,24 @@
language: go
go:
- 1.9.3
- 1.8.1
# Don't want default ./... here:
install:
- export PATH=$GOPATH/bin:$PATH
- mkdir -p $HOME/gopath/src/k8s.io
- mv $TRAVIS_BUILD_DIR $HOME/gopath/src/k8s.io/website && cd $HOME/gopath/src/k8s.io/website
# Fetch dependencies for us to run the tests in test/examples_test.go
- go get -t -v k8s.io/website/test
# Make sure we are testing against the correct branch
- pushd $GOPATH/src/k8s.io/kubernetes && git checkout release-1.10 && popd
- mv $TRAVIS_BUILD_DIR $HOME/gopath/src/k8s.io/kubernetes.github.io
# (1) Fetch dependencies for us to run the tests in test/examples_test.go
- go get -t -v k8s.io/kubernetes.github.io/test
# Simplified deduplication of dependencies.
- cp -L -R $GOPATH/src/k8s.io/kubernetes/vendor/ $GOPATH/src/
- rm -r $GOPATH/src/k8s.io/kubernetes/vendor/
# (2) Fetch md-check along with all its dependencies.
- git clone --depth=50 --branch=master https://github.com/kubernetes/md-check $HOME/gopath/src/k8s.io/md-check
- go get -t -v k8s.io/md-check
script:
# TODO(bep)
- go test -v k8s.io/website/test #fixed by https://github.com/kubernetes/website/pull/8388
#- ./verify-docs-format.sh
- go test -v k8s.io/kubernetes.github.io/test
- $GOPATH/bin/md-check --root-dir=$HOME/gopath/src/k8s.io/kubernetes.github.io
+10
View File
@@ -0,0 +1,10 @@
---
layout: docwithnav
title: 404 Error!
permalink: /404.html
no_canonical: true
---
<script src="/js/redirects.js"></script>
Sorry, this page was not found. :(
+2
View File
@@ -0,0 +1,2 @@
kubernetes.io
kubernet.es
+6 -6
View File
@@ -9,7 +9,7 @@ These are just guidelines, not rules. Use your best judgment, and feel free to p
### Code of Conduct
Kubernetes follows the [Cloud Native Computing Foundation (CNCF) Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to Sarah Novotny [sarahnovotny@google.com](mailto:sarahnovotny@google.com) and/or Dan Kohn [dan@linuxfoundation.org](mailto:dan@linuxfoundation.org).
Kubernetes follows the [Cloud Native Computing Foundation (CNCF) Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to Sarah Novotny [sarahnovotny@google.com](mailto:sarahnovotny@google.com) and/or Dan Kohn [dan@linuxfoundation.org](mailto:dan@linuxfoundation.org).
### Documentation and Site Decisions
@@ -17,7 +17,7 @@ The [Kubernetes SIG Docs Discussion Group](https://groups.google.com/forum/#!for
### Style Guides and Templates
Before submitting a pull request to create new content, please review the [Kubernetes.io style guide](http://kubernetes.io/docs/home/contribute/style-guide/) and follow the [instructions for using page templates](http://kubernetes.io/docs/home/contribute/page-templates/).
Before submitting a pull request to create new content, please review the [Kubernetes.io style guide](http://kubernetes.io/docs/contribute/style-guide/) and follow the [instructions for using page templates](http://kubernetes.io/docs/contribute/page-templates/).
## Contributing to Documentation
@@ -26,11 +26,11 @@ Before submitting a pull request to create new content, please review the [Kuber
Kubernetes.io uses github issues to track documentation issues and requests. If you see a documentation issue, submit an issue using the following steps:
1. Check the [kubernetes.io issues list](https://github.com/kubernetes/website/issues) as you might find out the issue is a duplicate.
2. Use the [included template for every new issue](https://github.com/kubernetes/website/issues/new). When you create a bug report, include as many details as possible and include suggested fixes to the issue.
1. Check the [kubernetes.io issues list](https://github.com/kubernetes/kubernetes.github.io/issues) as you might find out the issue is a duplicate.
2. Use the [included template for every new issue](https://github.com/kubernetes/kubernetes.github.io/issues/new). When you create a bug report, include as many details as possible and include suggested fixes to the issue.
Note that code issues should be filed against the main kubernetes repository, while documentation issues should go in the kubernetes.io repository.
Note that code issues should be filed against the main kubernetes repository, while documentation issues should go in the kubernetes.io repository.
### Submitting Documentation Pull Requests
If you're fixing an issue in the existing documentation, you should submit a PR against the master branch. Follow [these instructions to create a documentation pull request against the kubernetes.io repository](http://kubernetes.io/docs/home/contribute/create-pull-request/).
If youre fixing an issue in the existing documentation, you should submit a PR against the master branch. Follow [these instructions to create a documentation pull request against the kubernetes.io repository](http://kubernetes.io/docs/contribute/create-pull-request/).
-30
View File
@@ -1,30 +0,0 @@
# Credit to Julien Guyomard (https://github.com/jguyomard). This Dockerfile
# is essentially based on his Dockerfile at
# https://github.com/jguyomard/docker-hugo/blob/master/Dockerfile. The only significant
# change is that the Hugo version is now an overridable argument rather than a fixed
# environment variable.
FROM alpine:latest
MAINTAINER Luc Perkins <lperkins@linuxfoundation.org>
RUN apk add --no-cache \
curl \
git \
openssh-client \
rsync
ARG HUGO_VERSION
RUN mkdir -p /usr/local/src && \
cd /usr/local/src && \
curl -L https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_linux-64bit.tar.gz | tar -xz && \
mv hugo /usr/local/bin/hugo && \
curl -L https://bin.equinox.io/c/dhgbqpS8Bvy/minify-stable-linux-amd64.tgz | tar -xz && \
mv minify /usr/local/bin && \
addgroup -Sg 1000 hugo && \
adduser -Sg hugo -u 1000 -h /src hugo
WORKDIR /src
EXPOSE 1313
+20
View File
@@ -0,0 +1,20 @@
source "https://rubygems.org"
gem "jekyll", "3.2.1"
gem "jekyll-sass-converter", "1.3.0"
gem "minima", "1.1.0"
gem "kramdown", "1.11.1"
gem "liquid", "3.0.6"
gem "rouge", "1.11.1"
gem "jemoji", "0.7.0"
gem "jekyll-mentions", "1.2.0"
gem "jekyll-redirect-from", "0.11.0"
gem "jekyll-sitemap", "0.10.0"
gem "jekyll-feed", "0.5.1"
gem "jekyll-gist", "1.4.0"
gem "jekyll-paginate", "1.1.0"
gem "jekyll-coffeescript", "1.0.1"
gem "jekyll-seo-tag", "2.0.0"
gem "jekyll-github-metadata", "2.0.2"
gem "listen", "3.0.6"
gem "activesupport", "4.2.7"
+119
View File
@@ -0,0 +1,119 @@
GEM
remote: https://rubygems.org/
specs:
activesupport (4.2.7)
i18n (~> 0.7)
json (~> 1.7, >= 1.7.7)
minitest (~> 5.1)
thread_safe (~> 0.3, >= 0.3.4)
tzinfo (~> 1.1)
addressable (2.4.0)
coffee-script (2.4.1)
coffee-script-source
execjs
coffee-script-source (1.10.0)
colorator (1.1.0)
execjs (2.7.0)
faraday (0.9.2)
multipart-post (>= 1.2, < 3)
ffi (1.9.14)
forwardable-extended (2.6.0)
gemoji (2.1.0)
html-pipeline (2.4.2)
activesupport (>= 2)
nokogiri (>= 1.4)
i18n (0.7.0)
jekyll (3.2.1)
colorator (~> 1.0)
jekyll-sass-converter (~> 1.0)
jekyll-watch (~> 1.1)
kramdown (~> 1.3)
liquid (~> 3.0)
mercenary (~> 0.3.3)
pathutil (~> 0.9)
rouge (~> 1.7)
safe_yaml (~> 1.0)
jekyll-coffeescript (1.0.1)
coffee-script (~> 2.2)
jekyll-feed (0.5.1)
jekyll-gist (1.4.0)
octokit (~> 4.2)
jekyll-github-metadata (2.0.2)
jekyll (~> 3.1)
octokit (~> 4.0)
jekyll-mentions (1.2.0)
activesupport (~> 4.0)
html-pipeline (~> 2.3)
jekyll (~> 3.0)
jekyll-paginate (1.1.0)
jekyll-redirect-from (0.11.0)
jekyll (>= 2.0)
jekyll-sass-converter (1.3.0)
sass (~> 3.2)
jekyll-seo-tag (2.0.0)
jekyll (~> 3.1)
jekyll-sitemap (0.10.0)
jekyll-watch (1.5.0)
listen (~> 3.0, < 3.1)
jemoji (0.7.0)
activesupport (~> 4.0)
gemoji (~> 2.0)
html-pipeline (~> 2.2)
jekyll (>= 3.0)
json (1.8.3)
kramdown (1.11.1)
liquid (3.0.6)
listen (3.0.6)
rb-fsevent (>= 0.9.3)
rb-inotify (>= 0.9.7)
mercenary (0.3.6)
mini_portile2 (2.1.0)
minima (1.1.0)
minitest (5.9.0)
multipart-post (2.0.0)
nokogiri (1.6.8)
mini_portile2 (~> 2.1.0)
pkg-config (~> 1.1.7)
octokit (4.3.0)
sawyer (~> 0.7.0, >= 0.5.3)
pathutil (0.14.0)
forwardable-extended (~> 2.6)
pkg-config (1.1.7)
rb-fsevent (0.9.7)
rb-inotify (0.9.7)
ffi (>= 0.5.0)
rouge (1.11.1)
safe_yaml (1.0.4)
sass (3.4.22)
sawyer (0.7.0)
addressable (>= 2.3.5, < 2.5)
faraday (~> 0.8, < 0.10)
thread_safe (0.3.5)
tzinfo (1.2.2)
thread_safe (~> 0.1)
PLATFORMS
ruby
DEPENDENCIES
activesupport (= 4.2.7)
jekyll (= 3.2.1)
jekyll-coffeescript (= 1.0.1)
jekyll-feed (= 0.5.1)
jekyll-gist (= 1.4.0)
jekyll-github-metadata (= 2.0.2)
jekyll-mentions (= 1.2.0)
jekyll-paginate (= 1.1.0)
jekyll-redirect-from (= 0.11.0)
jekyll-sass-converter (= 1.3.0)
jekyll-seo-tag (= 2.0.0)
jekyll-sitemap (= 0.10.0)
jemoji (= 0.7.0)
kramdown (= 1.11.1)
liquid (= 3.0.6)
listen (= 3.0.6)
minima (= 1.1.0)
rouge (= 1.11.1)
BUNDLED WITH
1.11.2
@@ -14,7 +14,7 @@
**Page to Update:**
https://kubernetes.io/...
http://kubernetes.io/...
<!--Optional Information (remove the comment tags around information you would like to include)-->
<!--Kubernetes Version:-->
+1 -1
View File
@@ -378,7 +378,7 @@ Section 8 -- Interpretation.
Creative Commons is not a party to its public
licenses. Notwithstanding, Creative Commons may elect to apply one of
its public licenses to material it publishes and in those instances
will be considered the "Licensor." The text of the Creative Commons
will be considered the Licensor. The text of the Creative Commons
public licenses is dedicated to the public domain under the CC0 Public
Domain Dedication. Except for the limited purpose of indicating that
material is shared under a Creative Commons public license or as
+4 -22
View File
@@ -1,33 +1,15 @@
DOCKER = docker
HUGO_VERSION = 0.40.3
DOCKER_IMAGE = kubernetes-hugo
DOCKER_RUN = $(DOCKER) run --rm --interactive --tty --volume $(PWD):/src
.PHONY: all build sass build-preview help serve
.PONY: all build build-preview help serve
help: ## Show this help.
@awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST)
all: build ## Build site with production settings and put deliverables in _site.
sass: # Rebuild the SASS source into CSS
node-sass --output-style compact ./src/sass/styles.sass ./static/css/styles.css
node-sass --output-style compact ./src/sass/case_study_styles.sass ./static/css/case_study_styles.css
build: ## Build site with production settings and put deliverables in _site.
hugo
jekyll build
build-preview: ## Build site with drafts and future posts enabled.
hugo -D -F
jekyll build --drafts --future
serve: ## Boot the development server.
hugo server
docker-image:
$(DOCKER) build . --tag $(DOCKER_IMAGE) --build-arg HUGO_VERSION=$(HUGO_VERSION)
docker-build:
$(DOCKER_RUN) $(DOCKER_IMAGE) hugo
stage:
$(DOCKER_RUN) -p 1313:1313 $(DOCKER_IMAGE) hugo server --watch --bind 0.0.0.0
jekyll serve
+7 -10
View File
@@ -1,10 +1,7 @@
# Reviewers can /lgtm /approve but not sufficient for auto-merge without an
# approver
reviewers:
- sig-docs-en-reviews
# Approvers have all the ability of reviewers but their /approve makes
# auto-merge happen if a /lgtm exists, or vice versa, or they can do both
# No need for approvers to also be listed as reviewers
approvers:
- sig-docs-en-owners
assignees:
- lavalamp
- smarterclayton
- janetkuo
- pwittrock
- kelseyhightower
- jaredbhatti
-275
View File
@@ -1,275 +0,0 @@
aliases:
sig-api-machinery: #Team: API Server; GH: sig-api-machinery-pr-reviews; e.g. Annotations, Labels
- lavalamp
- sttts
- liggitt
- smarterclayton
- deads2k
sig-apps: #Team: Workloads; GH: sig-apps-pr-reviews; e.g. ConfigMaps, CronJobs, CustomResourceDefinitions, DaemonSets, Deployments, Jobs, Secrets, StatefulSets
- enisoc
- erictune
- foxish
- janetkuo
- kow3ns
- lukaszo
- mfojtik
- smarterclayton
- soltysh
- tnozicka
sig-architecture: #GH: sig-architecture-pr-reviews
- smarterclayton
- bgrant0607
sig-auth: #GH: sig-auth-pr-reviews
- php-coder
- liggitt
- mikedanese
- ericchiang
- mattmoyer
- enj
- deads2k
- davidopp
sig-autoscaling: #GH: sig-autoscaling-pr-reviews
- DirectXMan12
- bskiba
- aleksandra-malinowska
- MaciekPytel
- davidopp
- mwielgus
sig-aws: #Amazon AWS
- justinsb
- kris-nova
- chrislovecnm
- mfburnett
sig-azure: #Microsoft Azure
- andyzhangx
- feiskyer
- justaugustus
- karataliu
- khenidak
sig-big-data: #GH: sig-big-data-pr-reviews
- foxish
sig-cli: #Team: CLI; GH: sig-cli-pr-reviews; e.g. kubectl
- adohe
- deads2k
- derekwaynecarr
- dims
- dshulyak
- eparis
- ericchiang
- ghodss
- mengqiy
- rootfs
- shiywang
- smarterclayton
- soltysh
- sttts
sig-cluster-lifecycle-kubeadm-approvers: # Approving changes to kubeadm documentation
- timothysc
- lukemarsden
- luxas
- roberthbailey
- fabriziopandini
sig-cluster-lifecycle-kubeadm-reviewers: # Reviewing kubeadm documentation
- timothysc
- lukemarsden
- luxas
- roberthbailey
- fabriziopandini
- kad
- xiangpengzhao
- stealthybox
- liztio
- chuckha
- detiber
- dixudx
sig-cluster-ops:
- zehicle
- jdumars
sig-contribex: #aka Contributor Experience; GH: sig-contributor-experience-pr-reviews
- rmmh
- cblecker
- apelisse
- grodrigues3
- spxtr
sig-contributor-experience: #GH: sig-contributor-experience-pr-reviews
- rmmh
- cblecker
- apelisse
- grodrigues3
- spxtr
sig-docs: #Team: documentation; GH: sig-docs-maintainers
- bradamant3
- bradtopol
- chenopis
- jaredbhatti
- kbarnard10
- mistyhacks
- ryanmcginnis
- steveperry-53
- tengqm
- tfogo
- xiangpengzhao
- zacharysarah
- zhangxiaoyu-zidif
- zparnold
sig-docs-en-owners: #Team: Documentation; GH: sig-docs-en-owners
- bradamant3
- bradtopol
- chenopis
- jaredbhatti
- kbarnard10
- mistyhacks
- ryanmcginnis
- steveperry-53
- stewart-yu
- tengqm
- tfogo
- zacharysarah
- zparnold
sig-docs-en-reviews: #Team: Documentation; GH: sig-docs-pr-reviews
- jimangel
- rajakavitha1
- stewart-yu
- xiangpengzhao
- zhangxiaoyu
sig-docs-ja-owners: #Team: Japanese docs localization; GH: sig-docs-ja-owners
- cstoku
- nasa9084
- tnir
sig-docs-ja-reviews: #Team: Japanese docs PR reviews; GH:sig-docs-ja-reviews
- cstoku
- makocchi-git
- MasayaAoyama
- nasa9084
- tnir
sig-docs-ko-owners: #Team Korean docs localization; GH: sig-docs-ko-owners
- ClaudiaJKang
- gochist
sig-docs-ko-reviews: #Team Korean docs reviews; GH: sig-docs-ko-reviews
- ClaudiaJKang
- gochist
- ianychoi
sig-docs-zh-owners: #Team Chinese docs localization; GH: sig-docs-zh-owners
- dchen1107
- haibinxie
- hanjiayao
- lichuqiang
- tengqm
- xiangpengzhao
- zhangxiaoyu-zidif
sig-docs-zh-reviews: #Team Chinese docs reviews; GH: sig-docs-zh-reviews
- idealhack
- tengqm
- xiangpengzhao
- zhangxiaoyu-zidif
sig-federation: #Team: Federation; e.g. Federated Clusters
- csbell
sig-gcp: #Google Cloud Platform; GH: sig-gcp-pr-reviews
- abgworrall
sig-instrumentation: #GH: sig-instrumentation-pr-reviews; e.g. metrics, logging, events
- DirectXMan12
- x13n
- kawych
- brancz
- fabxc
- loburm
- piosz
- fgrzadkowski
sig-multicluster: #GH: sig-multicluster-pr-reviews; e.g. resiliency against availability zone outages; hybrid clouds; spanning multiple cloud providers; migration to public clouds
- madhusudancs
- marun
- jianhuiz
- shashidharatd
- nikhiljindal
- quinton-hoole
- mwielgus
- csbell
sig-network: #Team: Network; GH: sig-network-pr-reviews; e.g. Ingress, Network Policies, Services
- bowei
- caseydavenport
- danwinship
- dcbw
- dnardo
- freehan
- mrhohn
- nicksardo
- thockin
sig-node: #Team: Node; GH: sig-node-pr-reviews; e.g. Containers, Docker, Images, OS images, Pods, Registries
- Random-Liu
- dashpole
- dchen1107
- derekwaynecarr
- dims
- feiskyer
- mtaufen
- ncdc
- pmorie
- resouer
- sjpotter
- tallclair
- tmrts
- vishh
- yifan-gu
- yujuhong
sig-onprem: #On-premises; GH: sig-onprem-pr-reviews
- zen
- idvoretskyi
- pigmej
- feiskyer
- nebril
sig-openstack: #GH: sig-openstack-pr-reviews
- hogepodge
- dklyle
- rjmorse
sig-pm: #aka Product Management
- apsinha
- idvoretskyi
- calebamiles
sig-product-management:
- apsinha
- idvoretskyi
- calebamiles
sig-release: #GH: sig-release-pr-reviews
- calebamiles
- enisoc
- pwittrock
sig-rktnetes:
- calebamiles
sig-scalability: #GH: sig-scalability-pr-reviews
- jbeda
- spiffxp
- lavalamp
- countspongebob
sig-scheduling: #Team: Sharing; GH: sig-scheduling-pr-reviews; e.g. Scheduler
- bsalamat
- davidopp
- jayunit100
- k82cn
- resouer
- timothysc
- wojtek-t
sig-service-catalog: #GH: sig-service-catalog-pr-reviews; e.g. Service Broker
- pmorie
- jessfraz
- pwittrock
- droot
- seans3
sig-storage: #Team: Storage; GH: sig-storage-pr-reviews; e.g. Volumes
- childsb
- jsafrane
- rootfs
- saad-ali
- matchstick
- msau42
sig-testing: #GH: sig-testing-pr-reviews
- fejta
- ixdy
- rmmh
- spiffxp
- spxtr
sig-ui: #User Interface
- danielromlein
- floreks
sig-windows:
- michmike
+166 -37
View File
@@ -1,53 +1,182 @@
## Instructions for Contributing to the Kubernetes Documentation
## Instructions for Contributing to the Docs/Website
Welcome! We are very pleased you want to contribute to the Kubernetes documentation.
Welcome! We are very pleased you want to contribute to the documentation and/or website for Kubernetes.
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 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.
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 originally 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.
You can click the "Fork" button in the upper-right area of the screen to create a copy of our site on your GitHub account called a "fork." Make any changes you want in your fork, and when you are ready to send those changes to us, go to the index page for your fork and click "New Pull Request" to let us know about it.
For more information about contributing to the Kubernetes documentation, see:
* [Contributing to the Kubernetes Documentation](http://kubernetes.io/editdocs/)
* [Creating a Documentation Pull Request](http://kubernetes.io/docs/home/contribute/create-pull-request/)
* [Writing a New Topic](http://kubernetes.io/docs/home/contribute/write-new-topic/)
* [Review Issues](http://kubernetes.io/docs/home/contribute/review-issues/)
* [Staging Your Documentation Changes](http://kubernetes.io/docs/home/contribute/stage-documentation-changes/)
* [Using Page Templates](http://kubernetes.io/docs/home/contribute/page-templates/)
* [Documentation Style Guide](http://kubernetes.io/docs/home/contribute/style-guide/)
* [Creating a Documentation Pull Request](http://kubernetes.io/docs/contribute/create-pull-request/)
* [Writing a New Topic](http://kubernetes.io/docs/contribute/write-new-topic/)
* [Staging Your Documentation Changes](http://kubernetes.io/docs/contribute/stage-documentation-changes/)
* [Using Page Templates](http://kubernetes.io/docs/contribute/page-templates/)
## Building the site using Docker
## Automatic Staging for Pull Requests
If you'd like, you can build the Kubernetes docs using Docker. To get started, build the image locally:
When you create a pull request (either against master or the upcoming release), your changes are staged in a custom subdomain on Netlify so that you can see your changes in rendered form before the PR is merged. You can use this to verify that everything is correct before the PR gets merged. To view your changes:
```bash
$ make docker-image
- Scroll down to the PR's list of Automated Checks
- Click "Show All Checks"
- Look for "deploy/netlify"; you'll see "Deploy Preview Ready!" if staging was successful
- Click "Details" to bring up the staged site and navigate to your changes
# The underlying command:
$ docker build . \
--tag kubernetes-hugo \
--build-arg HUGO_VERSION=0.40.3
```
## Branch structure and staging
You can create an image for a different version of Hugo by changing the value of the `HUGO_VERSION` argument for the build. You *must* specify a version or the image will not build.
Once the `kubernetes-hugo` image has been built locally, you can build the site:
The current version of the website is served out of the `master` branch. To make changes to the live docs, such as bug fixes, broken links, typos, etc, **target your pull request to the master branch**
```bash
$ make docker-serve
The `release-1.x` branch stores changes for **upcoming releases of Kubernetes**. For example, the `release-1.5` branch has changes for the 1.5 release. These changes target branches (and *not* master) to avoid publishing documentation updates prior to the release for which they're relevant. If you have a change for an upcoming release of Kubernetes, **target your pull request to the appropriate release branch**.
# The underlying command:
$ docker run \
--rm \
--interactive \
--tty \
--volume $(PWD):/src \
kubernetes-hugo:latest \
hugo
```
The staging site for the next upcoming Kubernetes release is here: [http://kubernetes-io-vnext-staging.netlify.com/](http://kubernetes-io-vnext-staging.netlify.com/). The staging site reflects the current state of what's been merged in the release branch, or in other words, what the docs will look like for the next upcoming release. It's automatically updated as new PRs get merged.
As when building without using a Docker container, the results of the build will be published to the `public` directory (the default output directory for [Hugo](https://gohugo.io), the static site generator used to build this site).
## Staging the site locally (using Docker)
Don't like installing stuff? Download and run a local staging server with a single `docker run` command.
git clone https://github.com/kubernetes/kubernetes.github.io.git
cd kubernetes.github.io
docker run -ti --rm -v "$PWD":/k8sdocs -p 4000:4000 gcr.io/google-samples/k8sdocs:1.0
Then visit [http://localhost:4000](http://localhost:4000) to see our site. Any changes you make on your local machine will be automatically staged.
If you're interested you can view [the Dockerfile for this image](https://github.com/kubernetes/kubernetes.github.io/blob/master/staging-container/Dockerfile).
## Staging the site locally (from scratch setup)
The below commands to setup your environment for running GitHub pages locally. Then, any edits you make will be viewable
on a lightweight webserver that runs on your local machine.
This will typically be the fastest way (by far) to iterate on docs changes and see them staged, once you get this set up, but it does involve several install steps that take awhile to complete, and makes system-wide modifications.
Install Ruby 2.2 or higher. If you're on Linux, run these commands:
apt-get install software-properties-common
apt-add-repository ppa:brightbox/ruby-ng
apt-get install ruby2.2
apt-get install ruby2.2-dev
* If you're on a Mac, follow [these instructions](https://gorails.com/setup/osx/).
* If you're on a Windows machine you can use the [Ruby Installer](http://rubyinstaller.org/downloads/). During the installation make sure to check the option for *Add Ruby executables to your PATH*.
The remainder of the steps should work the same across operating systems.
To confirm you've installed Ruby correctly, at the command prompt run `gem --version` and you should get a response with your version number. Likewise you can confirm you have Git installed properly by running `git --version`, which will respond with your version of Git.
Install the GitHub Pages package, which includes Jekyll:
gem install github-pages
Clone our site:
git clone https://github.com/kubernetes/kubernetes.github.io.git
Make any changes you want. Then, to see your changes locally:
cd kubernetes.github.io
jekyll serve
Your copy of the site will then be viewable at: [http://localhost:4000](http://localhost:4000)
(or wherever Jekyll tells you).
## GitHub help
If you're a bit rusty with git/GitHub, you might want to read
[this](http://readwrite.com/2013/10/02/github-for-beginners-part-2) for a refresher.
## Common Tasks
### Edit Page Titles or Change the Left Navigation
Edit the yaml files in `/_data/` for the Guides, Reference, Samples, or Support areas.
You may have to exit and `jekyll clean` before restarting the `jekyll serve` to
get changes to files in `/_data/` to show up.
### Add Images
Put the new image in `/images/docs/` if it's for the documentation, and just `/images/` if it's for the website.
**For diagrams, we greatly prefer SVG files!**
### Include code from another file
To include a file that is hosted on this GitHub repo, insert this code:
<pre>&#123;% include code.html language="&lt;LEXERVALUE&gt;" file="&lt;RELATIVEPATH&gt;" ghlink="&lt;PATHFROMROOT&gt;" %&#125;</pre>
* `LEXERVALUE`: The language in which the file was written; must be [a value supported by Rouge](https://github.com/jneen/rouge/wiki/list-of-supported-languages-and-lexers).
* `RELATIVEPATH`: The path to the file you're including, relative to the current file.
* `PATHFROMROOT`: The path to the file relative to root, e.g. `/docs/admin/foo.yaml`
To include a file that is hosted in the external, main Kubernetes repo, make sure it's added to [/update-imported-docs.sh](https://github.com/kubernetes/kubernetes.github.io/blob/master/update-imported-docs.sh), and run it so that the file gets downloaded, then enter:
<pre>&#123;% include code.html language="&lt;LEXERVALUE&gt;" file="&lt;RELATIVEPATH&gt;" k8slink="&lt;PATHFROMK8SROOT&gt;" %&#125;</pre>
* `PATHFROMK8SROOT`: The path to the file relative to the root of [the Kubernetes repo](https://github.com/kubernetes/kubernetes/tree/release-1.2), e.g. `/examples/rbd/foo.yaml`
## Using tabs for multi-language examples
By specifying some inline CSV in a varable called `tabspec`, you can include a file
called `tabs.html` that generates tabs showing code examples in multiple langauges.
<pre>&#123;% capture tabspec %&#125;servicesample
JSON,json,service-sample.json,/docs/user-guide/services/service-sample.json
YAML,yaml,service-sample.yaml,/docs/user-guide/services/service-sample.yaml&#123;% endcapture %&#125;
&#123;% include tabs.html %&#125;</pre>
In English, this would read: "Create a set of tabs with the alias `servicesample`,
and have tabs visually labeled "JSON" and "YAML" that use `json` and `yaml` Rouge syntax highlighting, which display the contents of
`service-sample.{extension}` on the page, and link to the file in GitHub at (full path)."
Example file: [Pods: Multi-Container](http://kubernetes.io/docs/user-guide/pods/multi-container/).
## Use a global variable
The `/_config.yml` file defines some useful variables you can use when editing docs.
* `page.githubbranch`: The name of the GitHub branch on the Kubernetes repo that is associated with this branch of the docs. e.g. `release-1.2`
* `page.version` The version of Kubernetes associated with this branch of the docs. e.g. `v1.2`
* `page.docsbranch` The name of the GitHub branch on the Docs/Website repo that you are currently using. e.g. `release-1.1` or `master`
This keeps the docs you're editing aligned with the Kubernetes version you're talking about. For example, if you define a link like so, you'll never have to worry about it going stale in future doc branches:
<pre>View the README [here](http://releases.k8s.io/&#123;&#123;page.githubbranch&#125;&#125;/cluster/addons/README.md).</pre>
That, of course, will send users to:
[http://releases.k8s.io/release-1.2/cluster/addons/README.md](http://releases.k8s.io/release-1.2/cluster/addons/README.md)
(Or whatever Kubernetes release that docs branch is associated with.)
## Config yaml guidelines
Guidelines for config yamls that are included in the site docs. These
are the yaml or json files that contain Kubernetes object
configuration to be used with `kubectl create -f` Config yamls should
be:
* Separate deployable files, not embedded in the document, unless very
small variations of a full config.
* Included in the doc with the include code
[above.](#include-code-from-another-file)
* In the same directory as the doc that they are being used in
* If you are re-using a yaml from another doc, that is OK, just
leave it there, don't move it up to a higher level directory.
* Tested in
[test/examples_test.go](https://github.com/kubernetes/kubernetes.github.io/blob/master/test/examples_test.go)
* Follows
[best practices.](http://kubernetes.io/docs/user-guide/config-best-practices/)
Don't assume the reader has this repository checked out, use `kubectl
create -f https://github...` in example commands. For Docker images
used in config yamls, try to use an image from an existing Kubernetes
example. If creating an image for a doc, follow the
[example guidelines](https://github.com/kubernetes/kubernetes/blob/master/examples/guidelines.md#throughout)
section on "Docker images" from the Kubernetes repository.
## Partners
Kubernetes partners refers to the companies who contribute to the Kubernetes core codebase, extend their platform to support Kubernetes or provide managed services to users centered around the Kubernetes platform. Partners can get their services and offerings added to the [partner page](https://k8s.io/partners) by completing and submitting the [partner request form](https://goo.gl/qcSnZF). Once the information and assets are verified, the partner product/services will be listed in the partner page. This would typically take 7-10 days.
## Thank you!
Kubernetes thrives on community participation, and we really appreciate your
contributions to our site and our documentation!
Kubernetes thrives on community participation and we really appreciate your
contributions to our site and our documentation!
-15
View File
@@ -1,15 +0,0 @@
# Defined below are the security contacts for this repo.
#
# They are the contact point for the Product Security Team to reach out
# to for triaging and handling of incoming issues.
#
# The below names agree to abide by the
# [Embargo Policy](https://github.com/kubernetes/sig-release/blob/master/security-release-process-documentation/security-release-process.md#embargo-policy)
# and will be removed and replaced if they violate that agreement.
#
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE
# INSTRUCTIONS AT https://kubernetes.io/security/
chenopis
jaredbhatti
zacharysarah
+63
View File
@@ -0,0 +1,63 @@
name: Kubernetes
markdown: kramdown
kramdown:
input: GFM
html_to_native: true
hard_wrap: false
syntax_highlighter: rouge
baseurl: /
incremental: true
safe: false
lsi: false
defaults:
-
scope:
path: ""
values:
version: "v1.4"
githubbranch: "v1.4.12"
docsbranch: "release-1.4"
versions:
- fullversion: "v1.8.0"
version: "v1.8"
githubbranch: "v1.8.0"
docsbranch: "release-1.8"
url: https://kubernetes.io/docs/home/
- fullversion: "v1.7.3"
version: "v1.7"
githubbranch: "v1.7.3"
docsbranch: "release-1.7"
url: https://v1-7.docs.kubernetes.io/docs/home/
- fullversion: "v1.6.8"
version: "v1.6"
githubbranch: "v1.6.8"
docsbranch: "release-1.6"
url: https://v1-6.docs.kubernetes.io/docs/home/
- fullversion: "v1.5.7"
version: "v1.5"
githubbranch: "v1.5.7"
docsbranch: "release-1.5"
url: https://v1-5.docs.kubernetes.io/docs/
- fullversion: "v1.4.12"
version: "v1.4"
githubbranch: "v1.4.12"
docsbranch: "release-1.4"
url: https://v1-4.docs.kubernetes.io/docs/
deprecated: true
currentUrl: https://kubernetes.io/docs/home/
nextUrl: http://kubernetes-io-vnext-staging.netlify.com/
-
scope:
path: "docs"
values:
layout: docwithnav
showedit: true
permalink: pretty
gems:
- jekyll-redirect-from
include: [_headers]
+9
View File
@@ -0,0 +1,9 @@
bigheader: "Concepts"
abstract: "Detailed explanations of Kubernetes system concepts and abstractions."
toc:
- title: Concepts
path: /docs/concepts/
- title: Object Metadata
section:
- title: Annotations
path: /docs/concepts/object-metadata/annotations/
+5
View File
@@ -0,0 +1,5 @@
bigheader: "Kubernetes Documentation"
abstract: "Documentation for using and learning about Kubernetes."
toc:
- title: Kubernetes Documentation
path: /docs/
+2 -3
View File
@@ -1,11 +1,10 @@
tocs:
- docs-home
- guides
- setup
- tasks
- tutorials
- tasks
- concepts
- reference
- tools
- samples
- support
- imported
+304
View File
@@ -0,0 +1,304 @@
bigheader: "Guides"
abstract: "How to get started, and accomplish tasks, using Kubernetes."
toc:
- title: Guides
path: /docs/user-guide/
- title: Getting Started
section:
- title: What is Kubernetes?
path: /docs/whatisk8s/
- title: Installing Kubernetes on Linux with kubeadm
path: /docs/getting-started-guides/kubeadm/
- title: Installing Kubernetes on AWS with kops
path: /docs/getting-started-guides/kops/
- title: Hello World on Google Container Engine
path: /docs/hellonode/
- title: Installing kubectl
path: /docs/getting-started-guides/kubectl/
- title: Downloading or Building Kubernetes
path: /docs/getting-started-guides/binary_release/
- title: Online Training Course
path: https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615
- title: Accessing the Cluster
section:
- title: Installing and Setting up kubectl
path: /docs/user-guide/prereqs/
- title: Accessing Clusters
path: /docs/user-guide/accessing-the-cluster/
- title: Sharing Cluster Access with kubeconfig
path: /docs/user-guide/sharing-clusters/
- title: Authenticating Across Clusters with kubeconfig
path: /docs/user-guide/kubeconfig-file/
- title: User Guide
path: /docs/user-guide/
- title: Web UI (Dashboard)
path: /docs/user-guide/ui/
- title: Workload Deployment and Management
section:
- title: Launching, Exposing, and Killing Applications
path: /docs/user-guide/quick-start/
- title: Deploying Applications
path: /docs/user-guide/deploying-applications/
- title: Managing Resources
path: /docs/user-guide/managing-deployments/
- title: Replication Controller Operations
path: /docs/user-guide/replication-controller/operations/
- title: Resizing a Replication Controller
path: /docs/user-guide/resizing-a-replication-controller/
- title: Rolling Updates
path: /docs/user-guide/rolling-updates/
- title: Rolling Update Demo
path: /docs/user-guide/update-demo/
- title: Secrets Walkthrough
path: /docs/user-guide/secrets/walkthrough/
- title: Using ConfigMap
path: /docs/user-guide/configmap/
- title: Horizontal Pod Autoscaling
path: /docs/user-guide/horizontal-pod-autoscaling/walkthrough/
- title: Best Practices for Configuration
path: /docs/user-guide/config-best-practices/
- title: Using kubectl to Manage Resources
path: /docs/user-guide/working-with-resources/
- title: Garbage Collection (Beta)
path: /docs/user-guide/garbage-collection/
- title: Using NetworkPolicy
section:
- title: Example Walkthrough
path: /docs/getting-started-guides/network-policy/walkthrough/
- title: Using Calico for NetworkPolicy
path: /docs/getting-started-guides/network-policy/calico/
- title: Using Romana for NetworkPolicy
path: /docs/getting-started-guides/network-policy/romana/
- title: Batch Jobs
section:
- title: Jobs
path: /docs/user-guide/jobs/
- title: Parallel Processing using Expansions
path: /docs/user-guide/jobs/expansions/
- title: Coarse Parallel Processing using a Work Queue
path: /docs/user-guide/jobs/work-queue-1/
- title: Fine Parallel Processing using a Work Queue
path: /docs/user-guide/jobs/work-queue-2/
- title: Cron Jobs
path: /docs/user-guide/cron-jobs/
- title: Service Discovery and Load Balancing
section:
- title: Connecting Applications with Services
path: /docs/user-guide/connecting-applications/
- title: Service Operations
path: /docs/user-guide/services/operations/
- title: Creating an External Load Balancer
path: /docs/user-guide/load-balancer/
- title: Configuring Your Cloud Provider's Firewalls
path: /docs/user-guide/services-firewalls/
- title: Cross-cluster Service Discovery using Federated Services
path: /docs/user-guide/federation/federated-services/
- title: Containers and Pods
section:
- title: Running Your First Containers
path: /docs/user-guide/simple-nginx/
- title: Creating Single-Container Pods
path: /docs/user-guide/pods/single-container/
- title: Creating Multi-Container Pods
path: /docs/user-guide/pods/multi-container/
- title: Configuring Containers
path: /docs/user-guide/configuring-containers/
- title: Working with Containers in Production
path: /docs/user-guide/production-pods/
- title: Commands and Capabilities
path: /docs/user-guide/containers/
- title: Using Environment Variables
path: /docs/user-guide/environment-guide/
- title: Managing Compute Resources
path: /docs/user-guide/compute-resources/
- title: The Lifecycle of a Pod
path: /docs/user-guide/pod-states/
- title: Checking Pod Health
path: /docs/user-guide/liveness/
- title: Container Lifecycle Hooks
path: /docs/user-guide/container-environment/
- title: Assigning Pods to Nodes
path: /docs/user-guide/node-selection/
- title: Using the Downward API to Convey Pod Properties
path: /docs/user-guide/downward-api/
- title: Downward API Volumes
path: /docs/user-guide/downward-api/volume
- title: Persistent Volumes Walkthrough
path: /docs/user-guide/persistent-volumes/walkthrough/
- title: Bootstrapping Pet Sets
path: /docs/user-guide/petset/bootstrapping/
- title: Monitoring, Logging, and Debugging Containers
section:
- title: Resource Usage Monitoring
path: /docs/user-guide/monitoring/
- title: Logging
path: /docs/getting-started-guides/logging/
- title: Logging with Elasticsearch and Kibana
path: /docs/getting-started-guides/logging-elasticsearch/
- title: Running Commands in a Container with kubectl exec
path: /docs/user-guide/getting-into-containers/
- title: Connect with Proxies
path: /docs/user-guide/connecting-to-applications-proxy/
- title: Connect with Port Forwarding
path: /docs/user-guide/connecting-to-applications-port-forward/
- title: Using Explorer to Examine the Runtime Environment
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/explorer
- title: Creating a Cluster
section:
- title: Picking the Right Solution
path: /docs/getting-started-guides/
- title: Running Kubernetes on Your Local Machine
section:
- title: Running Kubernetes Locally via Minikube
path: /docs/getting-started-guides/minikube/
- title: Deprecated Alternatives
path: /docs/getting-started-guides/alternatives/
- title: Running Kubernetes on Turn-key Cloud Solutions
section:
- title: Running Kubernetes on Google Container Engine
path: https://cloud.google.com/container-engine/docs/before-you-begin/
- title: Running Kubernetes on Google Compute Engine
path: /docs/getting-started-guides/gce/
- title: Running Kubernetes on AWS EC2
path: /docs/getting-started-guides/aws/
- title: Running Kubernetes on Azure
path: /docs/getting-started-guides/azure/
- title: Running Kubernetes on Azure (Weave-based)
path: /docs/getting-started-guides/coreos/azure/
- title: Running Kubernetes on CenturyLink Cloud
path: /docs/getting-started-guides/clc/
- title: Running Kubernetes on IBM SoftLayer
path: https://github.com/patrocinio/kubernetes-softlayer
- title: Running Kubernetes on Custom Solutions
section:
- title: Creating a Custom Cluster from Scratch
path: /docs/getting-started-guides/scratch/
- title: Custom Cloud Solutions
section:
- title: CoreOS on AWS or GCE
path: /docs/getting-started-guides/coreos/
- title: Ubuntu on AWS or Joyent
path: /docs/getting-started-guides/juju/
- title: CoreOS on Rackspace
path: /docs/getting-started-guides/rackspace/
- title: On-Premise VMs
section:
- title: CoreOS on Vagrant
path: /docs/getting-started-guides/coreos/
- title: Cloudstack
path: /docs/getting-started-guides/cloudstack/
- title: VMware vSphere
path: /docs/getting-started-guides/vsphere/
- title: VMware Photon Controller
path: /docs/getting-started-guides/photon-controller/
- title: Juju
path: /docs/getting-started-guides/juju/
- title: DCOS
path: /docs/getting-started-guides/dcos/
- title: CoreOS on libvirt
path: /docs/getting-started-guides/libvirt-coreos/
- title: oVirt
path: /docs/getting-started-guides/ovirt/
- title: OpenStack Heat
path: /docs/getting-started-guides/openstack-heat/
- title: rkt
section:
- title: Running Kubernetes with rkt
path: /docs/getting-started-guides/rkt/
- title: Known Issues when Using rkt
path: /docs/getting-started-guides/rkt/notes/
- title: Kubernetes on Mesos
path: /docs/getting-started-guides/mesos/
- title: Kubernetes on Mesos on Docker
path: /docs/getting-started-guides/mesos-docker/
- title: Bare Metal
section:
- title: Offline
path: /docs/getting-started-guides/coreos/bare_metal_offline/
- title: Fedora via Ansible
path: /docs/getting-started-guides/fedora/fedora_ansible_config/
- title: Fedora (Single Node)
path: /docs/getting-started-guides/fedora/fedora_manual_config/
- title: Fedora (Multi Node)
path: /docs/getting-started-guides/fedora/flannel_multi_node_cluster/
- title: CentOS
path: /docs/getting-started-guides/centos/centos_manual_config/
- title: CoreOS
path: /docs/getting-started-guides/coreos
- title: Ubuntu
path: /docs/getting-started-guides/ubuntu/
- title: Validate Node Setup
path: /docs/admin/node-conformance
- title: Portable Multi-Node Cluster
path: /docs/getting-started-guides/docker-multinode/
- title: Building Large Clusters
path: /docs/admin/cluster-large/
- title: Running in Multiple Zones
path: /docs/admin/multiple-zones/
- title: Building High-Availability Clusters
path: /docs/admin/high-availability/
- title: Administering Clusters
section:
- title: Admin Guide
path: /docs/admin/
- title: Cluster Management Guide
path: /docs/admin/cluster-management/
- title: kubeadm reference
path: /docs/admin/kubeadm/
- title: Installing Addons
path: /docs/admin/addons/
- title: Sharing a Cluster with Namespaces
path: /docs/admin/namespaces/
- title: Namespaces Walkthrough
path: /docs/admin/namespaces/walkthrough/
- title: Setting Pod CPU and Memory Limits
path: /docs/admin/limitrange/
- title: Understanding Resource Quotas
path: /docs/admin/resourcequota/
- title: Applying Resource Quotas and Limits
path: /docs/admin/resourcequota/walkthrough/
- title: Kubernetes Components
path: /docs/admin/cluster-components/
- title: Configuring Kubernetes Use of etcd
path: /docs/admin/etcd/
- title: Federating Clusters
path: /docs/admin/federation/
- title: Using Multiple Clusters
path: /docs/admin/multi-cluster/
- title: Changing Cluster Size
path: https://github.com/kubernetes/kubernetes/wiki/User-FAQ#how-do-i-change-the-size-of-my-cluster/
- title: Configuring Multiple Schedulers
path: /docs/admin/multiple-schedulers/
- title: Networking in Kubernetes
path: /docs/admin/networking/
- title: Using DNS Pods and Services
path: /docs/admin/dns/
- title: Setting Up and Configuring DNS
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/cluster-dns
- title: Master <-> Node Communication
path: /docs/admin/master-node-communication/
- title: Network Plugins
path: /docs/admin/network-plugins/
- title: Static Pods
path: /docs/admin/static-pods/
- title: Configuring kubelet Garbage Collection
path: /docs/admin/garbage-collection/
- title: Configuring Out Of Resource Handling
path: /docs/admin/out-of-resource/
- title: Configuring Kubernetes with Salt
path: /docs/admin/salt/
- title: Monitoring Node Health
path: /docs/admin/node-problem/
- title: AppArmor
path: /docs/admin/apparmor/
+19
View File
@@ -0,0 +1,19 @@
overrides:
- path: docs/api-reference
- path: docs/user-guide/kubectl
- path: docs/admin/federation-apiserver.md
- path: docs/admin/federation-controller-manager.md
- path: docs/admin/kube-apiserver.md
- path: docs/admin/kube-controller-manager.md
- path: docs/admin/kube-proxy.md
- path: docs/admin/kube-scheduler.md
- path: docs/admin/kubelet.md
- changedpath: docs/api-reference/extensions/v1beta1/definitions.html _includes/v1.4/extensions-v1beta1-definitions.html
- changedpath: docs/api-reference/extensions/v1beta1/operations.html _includes/v1.4/extensions-v1beta1-operations.html
- changedpath: docs/api-reference/v1/definitions.html _includes/v1.4/v1-definitions.html
- changedpath: docs/api-reference/v1/operations.html _includes/v1.4/v1-operations.html
- copypath: k8s/federation/docs/api-reference/ docs/federation/
- copypath: k8s/cluster/saltbase/salt/fluentd-gcp/fluentd-gcp.yaml docs/getting-started-guides/fluentd-gcp.yaml
- copypath: k8s/examples/blog-logging/counter-pod.yaml docs/getting-started-guides/counter-pod.yaml
- copypath: k8s/examples/blog-logging/counter-pod.yaml docs/user-guide/counter-pod.yaml
+274
View File
@@ -0,0 +1,274 @@
bigheader: "Reference Documentation"
abstract: "Design docs, concept definitions, and references for APIs and CLIs."
toc:
- title: Reference Documentation
path: /docs/reference/
- title: Kubernetes API
section:
- title: Kubernetes API Overview
path: /docs/api/
- title: Accessing the API
section:
- title: Overview
path: /docs/admin/accessing-the-api/
- title: Authenticating
path: /docs/admin/authentication/
- title: Using Authorization Plugins
path: /docs/admin/authorization/
- title: Using Admission Controllers
path: /docs/admin/admission-controllers/
- title: Managing Service Accounts
path: /docs/admin/service-accounts-admin/
- title: Kubernetes API Operations
path: /docs/api-reference/v1/operations/
- title: Kubernetes API Definitions
path: /docs/api-reference/v1/definitions/
- title: Kubernetes API Swagger Spec
path: /kubernetes/third_party/swagger-ui/
- title: Autoscaling API
section:
- title: Autoscaling API Operations
path: /docs/api-reference/autoscaling/v1/operations/
- title: Autoscaling API Definitions
path: /docs/api-reference/autoscaling/v1/definitions/
- title: Batch API
section:
- title: Batch API Operations
path: /docs/api-reference/batch/v1/operations/
- title: Batch API Definitions
path: /docs/api-reference/batch/v1/definitions/
- title: Extensions API
section:
- title: Extensions API Operations
path: /docs/api-reference/extensions/v1beta1/operations/
- title: Extensions API Definitions
path: /docs/api-reference/extensions/v1beta1/definitions/
- title: kubectl CLI
section:
- title: kubectl Overview
path: /docs/user-guide/kubectl-overview/
- title: kubectl for Docker Users
path: /docs/user-guide/docker-cli-to-kubectl/
- title: kubectl Usage Conventions
path: /docs/user-guide/kubectl-conventions/
- title: JSONpath Support
path: /docs/user-guide/jsonpath/
- title: kubectl Cheat Sheet
path: /docs/user-guide/kubectl-cheatsheet/
- title: kubectl Commands
section:
- title: kubectl
path: /docs/user-guide/kubectl/
- title: kubectl annotate
path: /docs/user-guide/kubectl/kubectl_annotate/
- title: kubectl api-versions
path: /docs/user-guide/kubectl/kubectl_api-versions/
- title: kubectl apply
path: /docs/user-guide/kubectl/kubectl_apply/
- title: kubectl attach
path: /docs/user-guide/kubectl/kubectl_attach/
- title: kubectl autoscale
path: /docs/user-guide/kubectl/kubectl_autoscale/
- title: kubectl cluster-info
path: /docs/user-guide/kubectl/kubectl_cluster-info/
- title: kubectl config
path: /docs/user-guide/kubectl/kubectl_config/
- title: kubectl config current-context
path: /docs/user-guide/kubectl/kubectl_config_current-context/
- title: kubectl config set-cluster
path: /docs/user-guide/kubectl/kubectl_config_set-cluster/
- title: kubectl config set-context
path: /docs/user-guide/kubectl/kubectl_config_set-context/
- title: kubectl config set-credentials
path: /docs/user-guide/kubectl/kubectl_config_set-credentials/
- title: kubectl config set
path: /docs/user-guide/kubectl/kubectl_config_set/
- title: kubectl config unset
path: /docs/user-guide/kubectl/kubectl_config_unset/
- title: kubectl config use-context
path: /docs/user-guide/kubectl/kubectl_config_use-context/
- title: kubectl config view
path: /docs/user-guide/kubectl/kubectl_config_view/
- title: kubectl convert
path: /docs/user-guide/kubectl/kubectl_convert/
- title: kubectl cordon
path: /docs/user-guide/kubectl/kubectl_cordon/
- title: kubectl create
path: /docs/user-guide/kubectl/kubectl_create/
- title: kubectl create configmap
path: /docs/user-guide/kubectl/kubectl_create_configmap/
- title: kubectl create namespace
path: /docs/user-guide/kubectl/kubectl_create_namespace/
- title: kubectl create secret docker-registry
path: /docs/user-guide/kubectl/kubectl_create_secret_docker-registry/
- title: kubectl create secret
path: /docs/user-guide/kubectl/kubectl_create_secret/
- title: kubectl create secret generic
path: /docs/user-guide/kubectl/kubectl_create_secret_generic/
- title: kubectl create serviceaccount
path: /docs/user-guide/kubectl/kubectl_create_serviceaccount/
- title: kubectl delete
path: /docs/user-guide/kubectl/kubectl_delete/
- title: kubectl describe
path: /docs/user-guide/kubectl/kubectl_describe/
- title: kubectl drain
path: /docs/user-guide/kubectl/kubectl_drain/
- title: kubectl edit
path: /docs/user-guide/kubectl/kubectl_edit/
- title: kubectl exec
path: /docs/user-guide/kubectl/kubectl_exec/
- title: kubectl explain
path: /docs/user-guide/kubectl/kubectl_explain/
- title: kubectl expose
path: /docs/user-guide/kubectl/kubectl_expose/
- title: kubectl get
path: /docs/user-guide/kubectl/kubectl_get/
- title: kubectl label
path: /docs/user-guide/kubectl/kubectl_label/
- title: kubectl logs
path: /docs/user-guide/kubectl/kubectl_logs/
- title: kubectl patch
path: /docs/user-guide/kubectl/kubectl_patch/
- title: kubectl port-forward
path: /docs/user-guide/kubectl/kubectl_port-forward/
- title: kubectl proxy
path: /docs/user-guide/kubectl/kubectl_proxy/
- title: kubectl replace
path: /docs/user-guide/kubectl/kubectl_replace/
- title: kubectl rolling-update
path: /docs/user-guide/kubectl/kubectl_rolling-update/
- title: kubectl rollout
path: /docs/user-guide/kubectl/kubectl_rollout/
- title: kubectl rollout history
path: /docs/user-guide/kubectl/kubectl_rollout_history/
- title: kubectl rollout pause
path: /docs/user-guide/kubectl/kubectl_rollout_pause/
- title: kubectl rollout resume
path: /docs/user-guide/kubectl/kubectl_rollout_resume/
- title: kubectl rollout undo
path: /docs/user-guide/kubectl/kubectl_rollout_undo/
- title: kubectl run
path: /docs/user-guide/kubectl/kubectl_run/
- title: kubectl scale
path: /docs/user-guide/kubectl/kubectl_scale/
- title: kubectl uncordon
path: /docs/user-guide/kubectl/kubectl_uncordon/
- title: kubectl version
path: /docs/user-guide/kubectl/kubectl_version/
- title: Superseded and Deprecated Commands
section:
- title: kubectl namespace
path: /docs/user-guide/kubectl/kubectl_namespace/
- title: kubectl stop
path: /docs/user-guide/kubectl/kubectl_stop/
- title: Kubernetes Components
section:
- title: kube-apiserver
path: /docs/admin/kube-apiserver/
- title: kube-controller-manager
path: /docs/admin/kube-controller-manager/
- title: kube-proxy
path: /docs/admin/kube-proxy/
- title: kube-scheduler
path: /docs/admin/kube-scheduler/
- title: kubelet
path: /docs/admin/kubelet/
- title: Glossary
section:
- title: Annotations
path: /docs/user-guide/annotations/
- title: Daemon Sets
path: /docs/admin/daemons/
- title: Deployments
path: /docs/user-guide/deployments/
- title: Horizontal Pod Autoscaling
path: /docs/user-guide/horizontal-pod-autoscaling/
- title: Images
path: /docs/user-guide/images/
- title: Ingress Resources
path: /docs/user-guide/ingress/
- title: Jobs
path: /docs/user-guide/jobs/
- title: Labels and Selectors
path: /docs/user-guide/labels/
- title: Names
path: /docs/user-guide/identifiers/
- title: Namespaces
path: /docs/user-guide/namespaces/
- title: Network Policies
path: /docs/user-guide/networkpolicies/
- title: Nodes
path: /docs/admin/node/
- title: Persistent Volumes
path: /docs/user-guide/persistent-volumes/
- title: Pet Sets
path: /docs/user-guide/petset/
- title: Pods
path: /docs/user-guide/pods/
- title: Pod Security Policies
path: /docs/user-guide/pod-security-policy/
- title: Replica Sets
path: /docs/user-guide/replicasets/
- title: Replication Controller
path: /docs/user-guide/replication-controller/
- title: Resource Quotas
path: /docs/admin/resourcequota/
- title: Cron Jobs
path: /docs/user-guide/cron-jobs/
- title: Secrets
path: /docs/user-guide/secrets/
- title: Security Context
path: /docs/user-guide/security-context/
- title: Services
path: /docs/user-guide/services/
- title: Service Accounts
path: /docs/user-guide/service-accounts/
- title: Third Party Resources
path: /docs/user-guide/thirdpartyresources/
- title: Volumes
path: /docs/user-guide/volumes/
- title: Kubernetes Design Docs
section:
- title: Kubernetes Architecture
path: https://github.com/kubernetes/kubernetes/blob/release-1.3/docs/design/architecture.md
- title: Kubernetes Design Overview
path: https://github.com/kubernetes/kubernetes/blob/release-1.3/docs/design/
- title: Kubernetes Identity and Access Management
path: https://github.com/kubernetes/kubernetes/blob/release-1.3/docs/design/access.md
- title: Kubernetes OpenVSwitch GRE/VxLAN networking
path: /docs/admin/ovs-networking/
- title: Security Contexts
path: https://github.com/kubernetes/kubernetes/blob/release-1.3/docs/design/security_context.md
- title: Security in Kubernetes
path: https://github.com/kubernetes/kubernetes/blob/release-1.3/docs/design/security.md
- title: Federation
section:
- title: Federation User Guide
path: /docs/user-guide/federation/
- title: Federated Events
path: /docs/user-guide/federation/events/
- title: Federated Ingress
path: /docs/user-guide/federation/federated-ingress/
- title: Federated Namespaces
path: /docs/user-guide/federation/namespaces/
- title: Federated ReplicaSets
path: /docs/user-guide/federation/replicasets/
- title: Federated Secrets
path: /docs/user-guide/federation/secrets/
- title: Federation API
path: /docs/federation/api-reference/README/
- title: Federation Components
section:
- title: federation-apiserver
path: /docs/admin/federation-apiserver
- title : federation-controller-mananger
path: /docs/admin/federation-controller-manager
+79
View File
@@ -0,0 +1,79 @@
bigheader: "Samples"
abstract: "A collection of example applications that show how to use Kubernetes."
toc:
- title: Samples
path: /docs/samples/
- title: Storage / Database / KV
section:
- title: Apache Cassandra Database
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/cassandra
- title: Ceph
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/rbd/
- title: CephFS
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/cephfs/
- title: CockroachDB
path: https://github.com/kubernetes/kubernetes/tree/release-1.4/examples/cockroachdb/
- title: GlusterFS
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/glusterfs/
- title: Hazelcast
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/hazelcast
- title: iSCSI
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/iscsi/
- title: MySQL Galera
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/mysql-galera
- title: NFS
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/nfs/
- title: Redis
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/redis/
- title: RethinkDB
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/rethinkdb/
- title: Vitess
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/vitess/
- title: Big Data
section:
- title: Apache Spark
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/spark
- title: Apache Storm
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/storm
- title: Messaging / Queueing
section:
- title: Celery + RabbitMQ
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/celery-rabbitmq
- title: Hazelcast
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/hazelcast
- title: Miscellaneous
section:
- title: Meteor Applications
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/meteor/
- title: OpenShift Origin
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/openshift-origin/
- title: Selenium
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/selenium/
- title: Monitoring and Logging
section:
- title: Elasticsearch
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/elasticsearch/
- title: NewRelic
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/newrelic
- title: Multi-tier Applications
section:
- title: Guestbook - Go Server
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/guestbook-go/
- title: GuestBook - PHP Server
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/guestbook/
- title: MEAN stack on Google Cloud Platform
path: /docs/getting-started-guides/meanstack/
- title: MySQL + Wordpress
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/mysql-wordpress-pd/
- title: MySQL + Phabricator Server
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/phabricator/
- title: Nodejs + Mongo
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/nodesjs-mongodb
- title: Petstore
path: https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/k8petstore/
+55
View File
@@ -0,0 +1,55 @@
bigheader: "Support"
abstract: "Troubleshooting resources, frequently asked questions, and community support channels."
toc:
- title: Support
path: /docs/troubleshooting/
- title: Contributing to the Kubernetes Docs
section:
- title: Creating a Documentation Pull Request
path: /docs/contribute/create-pull-request/
- title: Writing a New Topic
path: /docs/contribute/write-new-topic/
- title: Staging Your Documentation Changes
path: /docs/contribute/stage-documentation-changes/
- title: Using Page Templates
path: /docs/contribute/page-templates/
- title: Documentation Style Guide
path: /docs/contribute/style-guide/
- title: Troubleshooting
section:
- title: Debugging Pods and Replication Controllers
path: /docs/user-guide/debugging-pods-and-replication-controllers/
- title: Application Introspection and Debugging
path: /docs/user-guide/introspection-and-debugging/
- title: Retrieving Logs
path: /docs/user-guide/logging/
- title: Troubleshooting Applications
path: /docs/user-guide/application-troubleshooting/
- title: Troubleshooting Clusters
path: /docs/admin/cluster-troubleshooting/
- title: Debugging Services
path: /docs/user-guide/debugging-services/
- title: Frequently Asked Questions
section:
- title: User FAQ
path: https://github.com/kubernetes/kubernetes/wiki/User-FAQ/
- title: Debugging FAQ
path: https://github.com/kubernetes/kubernetes/wiki/Debugging-FAQ/
- title: Services FAQ
path: https://github.com/kubernetes/kubernetes/wiki/Services-FAQ/
- title: Other Resources
section:
- title: Kubernetes Issue Tracker on GitHub
path: https://github.com/kubernetes/kubernetes/issues/
- title: Report a Security Vulnerability
path: /docs/reporting-security-issues/
- title: Release Notes
path: https://github.com/kubernetes/kubernetes/releases/
- title: Release Roadmap
path: https://github.com/kubernetes/kubernetes/milestones/
- title: Contributing to Kubernetes Documentation
path: /editdocs/
+34
View File
@@ -0,0 +1,34 @@
bigheader: "Tasks"
abstract: "Step-by-step instructions for performing operations with Kuberentes."
toc:
- title: Tasks
path: /docs/tasks/
- title: Configuring Pods and Containers
section:
- title: Defining Environment Variables for a Container
path: /docs/tasks/configure-pod-container/define-environment-variable-container/
- title: Defining a Command and Arguments for a Container
path: /docs/tasks/configure-pod-container/define-command-argument-container/
- title: Assigning CPU and RAM Resources to a Container
path: /docs/tasks/configure-pod-container/assign-cpu-ram-container/
- title: Accessing Applications in a Cluster
section:
- title: Using Port Forwarding to Access Applications in a Cluster
path: /docs/tasks/access-application-cluster/port-forward-access-application-cluster/
- title: Debugging Applications in a Cluster
section:
- title: Determining the Reason for Pod Failure
path: /docs/tasks/debug-application-cluster/determine-reason-pod-failure/
- title: Accessing the Kubernetes API
section:
- title: Using an HTTP Proxy to Access the Kubernetes API
path: /docs/tasks/access-kubernetes-api/http-proxy-access-api/
- title: Administering a Cluster
section:
- title: Assigning Pods to Nodes
path: /docs/tasks/administer-cluster/assign-pods-nodes/
+5
View File
@@ -0,0 +1,5 @@
bigheader: "Tools"
abstract: "Tools to help you use and enhance Kubernetes."
toc:
- title: Tools
path: /docs/tools/
+57
View File
@@ -0,0 +1,57 @@
bigheader: "Tutorials"
abstract: "Detailed walkthroughs of common Kubernetes operations and workflows."
toc:
- title: Tutorials
path: /docs/tutorials/
- title: Kubernetes Basics
section:
- title: Overview
path: /docs/tutorials/kubernetes-basics/
- title: 1. Create a Cluster
section:
- title: Using Minikube to Create a Cluster
path: /docs/tutorials/kubernetes-basics/cluster-intro/
- title: Interactive Tutorial - Creating a Cluster
path: /docs/tutorials/kubernetes-basics/cluster-interactive/
- title: 2. Deploy an App
section:
- title: Using kubectl to Create a Deployment
path: /docs/tutorials/kubernetes-basics/deploy-intro/
- title: Interactive Tutorial - Deploying an App
path: /docs/tutorials/kubernetes-basics/deploy-interactive/
- title: 3. Explore Your App
section:
- title: Viewing Pods and Nodes
path: /docs/tutorials/kubernetes-basics/explore-intro/
- title: Interactive Tutorial - Exploring Your App
path: /docs/tutorials/kubernetes-basics/explore-interactive/
- title: 4. Expose Your App Publicly
section:
- title: Using a Service to Expose Your App
path: /docs/tutorials/kubernetes-basics/expose-intro/
- title: Interactive Tutorial - Exposing Your App
path: /docs/tutorials/kubernetes-basics/expose-interactive/
- title: 5. Scale Your App
section:
- title: Running Multiple Instances of Your App
path: /docs/tutorials/kubernetes-basics/scale-intro/
- title: Interactive Tutorial - Scaling Your App
path: /docs/tutorials/kubernetes-basics/scale-interactive/
- title: 6. Update Your App
section:
- title: Performing a Rolling Update
path: /docs/tutorials/kubernetes-basics/update-intro/
- title: Interactive Tutorial - Updating Your App
path: /docs/tutorials/kubernetes-basics/update-interactive/
- title: Stateless Applications
section:
- title: Running a Stateless Application Using a Deployment
path: /docs/tutorials/stateless-application/run-stateless-application-deployment/
- title: Using a Service to Access an Application in a Cluster
path: /docs/tutorials/stateless-application/expose-external-ip-address-service/
- title: Exposing an External IP Address to Access an Application in a Cluster
path: /docs/tutorials/stateless-application/expose-external-ip-address/
- title: Stateful Applications
section:
- title: Running a Single-Instance Stateful Application
path: /docs/tutorials/stateful-application/run-stateful-application/
+313
View File
@@ -0,0 +1,313 @@
<style>
#caseStudyTitle {
margin-top: 1em !important;
}
.gridPage p {
color: rgb(26,26,26) !important;
margin-left: 0 !important;
padding-left: 0 !important;
font-weight: 300 !important;
}
.gridPage #mainContent {
padding: 0;
}
.gridPage #mainContent .content {
padding-top: 0;
}
.gridPage main {
max-width: 1100px !important;
}
.gridPage .content {
position: relative;
margin: 0 auto 50px;
max-width: 90%;
}
.gridPage .content p {
line-height: 24px !important;
}
.gridPage .content h3 {
padding: 0 !important;
}
.gridPage #hero h5 {
padding-left: 20px;
margin: 0;
}
.case-studies {
position: relative;
display: flex;
justify-content: space-between;
flex-wrap: wrap;
margin-top: 50px;
}
.case-study {
position: relative;
width: 50%;
padding: 0 40px 0 242px;
margin-bottom: 60px;
min-height: 152px;
}
.case-study:nth-child(3), .case-study:nth-child(4) {
margin-bottom: 0;
}
.case-study img {
position: absolute;
top: 0;
left: 0;
}
.gridPage #mainContent .content .case-study p {
font-family: "Roboto", sans-serif;
font-size: 16px;
padding: 0;
}
p.attrib {
font-style: italic;
}
.gridPage #video {
background: #f9f9f9;
height: auto;
/*height: 340px;*/
}
.gridPage #video main {
position: relative;
max-width: 900px !important;
height: 100%;
display: flex;
justify-content: center;
align-items: center;
padding: 50px 20px;
}
.gridPage #video main > div {
width: 50%;
}
.gridPage #video main #zulilyLogo {
width: 100px;
}
.gridPage #video main img {
max-width: 100%;
}
.gridPage #video h3 {
font-size: 32px;
font-weight: 300;
line-height: 38px;
max-width: 80%;
margin: 0 0 1em 0;
}
.gridPage #video p {
margin: 0;
}
.gridPage #video p.attrib {
margin-bottom: 20px;
}
.gridPage #video button > h6 {
font-size: 18px;
font-weight: 500;
margin: 1em 0;
color: #326de6;
}
.gridPage #users {
padding: 50px;
}
.gridPage #users main {
max-width: 1150px !important;
}
.gridPage #users main h3 {
padding-left: 20px;
margin-bottom: 20px;
}
.gridPage #usersGrid {
position: relative;
display: flex;
flex-wrap: wrap;
justify-content: center;
}
.gridPage #usersGrid a {
display: inline-block;
margin: 5px;
}
.gridPage #usersGrid a img {
box-shadow: 1px 1px 2px transparent;
transition: box-shadow 0.25s;
}
.gridPage #usersGrid a img:hover {
box-shadow: 1px 1px 2px #cccccc;
}
.gridPage #usersGrid a:last-child img,
.gridPage #usersGrid a:last-child img:hover {
box-shadow: 1px 1px 2px transparent;
}
.tell-your-story {
border: 1px solid #dddddd;
border-radius: 6px;
box-shadow: 1px 2px 2px #dddddd;
}
.gridPage .feature {
position: relative;
padding: 20px 0 20px 242px;
}
.gridPage .feature img {
position: absolute;
top: 20px;
left: 0;
}
section.bullets {
background-color: #eeeeee;
margin-bottom: 50px;
}
section.bullets main {
position: relative;
max-width: 1100px;
padding: 50px 0;
}
section.bullets .content {
position: relative;
display: flex;
flex-wrap: wrap;
margin-bottom: 0 !important;
}
.bullet {
position: relative;
width: 50%;
padding: 15px 30px;
}
.bullet h4 {
margin-bottom: 0.5em;
}
.bullet li {
margin-left: 1.25em;
list-style: disc;
font-weight: 300;
color: rgb(26,26,26);
line-height: 1.5em;
margin-bottom: 0.5em;
}
.details h4, p {
margin-bottom: 0.5em;
}
.gridPage .feature p.quote {
font-size: 20px;
line-height: 28px !important;
}
@media screen and (max-width: 1024px){
.case-study {
padding: 0 10%;
margin-bottom: 50px;
}
.case-study img {
position: relative;
}
.case-study p.quote {
margin-top: 20px !important;
}
.case-study p.attrib {
font-style: italic;
}
}
@media screen and (max-width: 900px){
.gridPage #video main {
flex-direction: column;
align-items: center;
}
.gridPage #video main > div {
width: 400px;
}
.gridPage #video main > div + div {
margin-top: 30px;
}
.gridPage #video h3 {
max-width: 100%;
}
}
@media screen and (max-width: 640px){
.case-study {
width: 100%;
}
.case-study:nth-child(3) {
margin-bottom: 60px;
}
.case-study img {
left: 50%;
transform: translateX(-50%);
}
.gridPage .feature {
margin-top: 50px;
padding: 180px 0 0;
}
.gridPage .feature img {
top: 0;
left: 50%;
transform: translateX(-50%);
}
}
@media screen and (max-width: 480px){
.gridPage #hero {
padding-right: 20px;
padding-left: 20px;
}
.gridPage #video main > div {
width: 80%;
min-width: 280px;
}
.bullet {
width: 100%;
}
}
</style>
+11
View File
@@ -0,0 +1,11 @@
{% capture samplecode %}{% include_relative {{include.file}} %}{% endcapture %}
{% if include.k8slink %}{% capture ghlink %}https://raw.githubusercontent.com/kubernetes/kubernetes/blob/{{page.githubbranch}}{{include.k8slink}}{% endcapture %}{% endif %}
{% if include.ghlink %}{% capture ghlink %}https://raw.githubusercontent.com/kubernetes/kubernetes.github.io/{{page.docsbranch}}{{include.ghlink}}{% endcapture %}{% endif %}
{% capture mysample %}
```{{include.language}}
{{ samplecode | raw | strip }}
```
{: id="{{include.file | handleize}}"}
{% endcapture %}
<table class="includecode"><thead><tr><th>{% if ghlink %}<a href="{{ghlink}}" download="{{include.file}}">{% endif %}<code>{{include.file}}</code></a><img src="/images/copycode.svg" style="max-height:24px" onClick="copyCode('{{include.file | handleize}}')" title="Copy {{include.file}} to clipboard"></th></tr></thead>
<tr><td>{{ mysample | markdownify }}</td></tr></table>
+12
View File
@@ -0,0 +1,12 @@
{% if page.deprecated %}
<section id="deprecationWarning">
<main>
<div class="content deprecation-warning">
<h3>
Documentation for Kubernetes {{ page.version}} is no longer actively maintained. The version you are currently viewing is a static snapshot.
For up-to-date documentation, see the <a href="{{ page.currentUrl }}">latest</a> version.
</h3>
</div>
</main>
</section>
{% endif %}
+53
View File
@@ -0,0 +1,53 @@
<button class="flyout-button" onclick="kub.toggleToc()"></button>
<style>
.cse .gsc-control-cse, .gsc-control-cse, {
padding: 0;
}
.gsc-control-cse table, .gsc-control-cse-en table {
margin:0px !important;
}
.gsc-above-wrapper-area {
border-bottom: 0;
}
</style>
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-36037335-10', 'auto');
ga('send', 'pageview');
// hide docs nav area if no nav is present, or if nav only contains a link to the current page
(function () {
window.addEventListener('DOMContentLoaded', init)
// play nice with our neighbors
function init() {
window.removeEventListener('DOMContentLoaded', init)
hideNav()
}
function hideNav(toc){
if (!toc) toc = document.querySelector('#docsToc')
var container = toc.querySelector('.container')
// container is built dynamically, so it may not be present on the first runloop
if (container) {
if (container.childElementCount === 0 || toc.querySelectorAll('a.item').length === 1) {
toc.style.display = 'none'
document.getElementById('docsContent').style.width = '100%'
}
} else {
requestAnimationFrame(function () {
hideNav(toc)
})
}
}
})();
</script>
<!-- Commenting out AnswerDash for now; we need to work on our list of questions/answers/design first
<!-- Start of AnswerDash script <script>var AnswerDash;!function(e,t,n,s,a){if(!t.getElementById(s)){var i,r=t.createElement(n),c=t.getElementsByTagName(n)[0];e[a]||(i=e[a]=function(){i.__oninit.push(arguments)},i.__oninit=[]),r.type="text/javascript",r.async=!0,r.src="https://p1.answerdash.com/answerdash.min.js?siteid=756",r.setAttribute("id",s),c.parentNode.insertBefore(r,c)}}(window,document,"script","answerdash-script","AnswerDash");</script> <!-- End of AnswerDash script -->
+29
View File
@@ -0,0 +1,29 @@
<footer>
<main class="light-text">
<nav>
<a href="/docs/hellonode/">Get Started</a>
<a href="/docs/">Documentation</a>
<a href="http://blog.kubernetes.io/">Blog</a>
<a href="/partners/">Partners</a>
<a href="/community/">Community</a>
<a href="/case-studies/">Case Studies</a>
</nav>
<div class="social">
<div>
<a href="https://twitter.com/kubernetesio" class="twitter"><span>twitter</span></a>
<a href="https://github.com/kubernetes/kubernetes" class="github"><span>Github</span></a>
<a href="http://slack.k8s.io/" class="slack"><span>Slack</span></a>
</div>
<div>
<a href="http://stackoverflow.com/questions/tagged/kubernetes" class="stack-overflow"><span>Stack Overflow</span></a>
<a href="https://groups.google.com/forum/#!forum/kubernetes-users" class="mailing-list"><span>Mailing List</span></a>
<a href="https://calendar.google.com/calendar/embed?src=nt2tcnbtbied3l6gi2h29slvc0%40group.calendar.google.com" class="calendar"><span>Events Calendar</span></a>
</div>
<div>
<a href="//get.k8s.io" class="button">Download K8s</a>
<a href="https://github.com/kubernetes/kubernetes" class="button">Contribute to the K8s codebase</a>
</div>
</div>
<div id="miceType" class="center">&copy; {{ 'now' | date: "%Y" }} The Kubernetes Authors | Distributed under <a href="https://github.com/kubernetes/kubernetes.github.io/blob/master/LICENSE" class="light-text">CC BY 4.0</a></div>
</main>
</footer>
+81
View File
@@ -0,0 +1,81 @@
{% if page.title %}{% assign title=page.title %}{% endif %}
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
{% if !page.no_canonical %}<link rel="canonical" href="http://kubernetes.io{{page.url}}" />{% endif %}
<link rel="shortcut icon" type="image/png" href="/images/favicon.png">
<link href='https://fonts.googleapis.com/css?family=Roboto:400,100,100italic,300,300italic,400italic,500,500italic,700,700italic,900,900italic' rel='stylesheet' type='text/css'>
<link rel="stylesheet" href='https://fonts.googleapis.com/css?family=Roboto+Mono' type='text/css'>
<link rel="stylesheet" href="/css/styles.css"/>
<link rel="stylesheet" href="/css/jquery-ui.min.css">
<link rel="stylesheet" href="/css/sweetalert.css">
<script src="/js/jquery-2.2.0.min.js"></script>
<script src="/js/jquery-ui.min.js"></script>
<script src="/js/script.js"></script>
<script src="/js/sweetalert.min.js"></script>
<script src="/js/bootstrap.min.js"></script>
<title>Kubernetes - {{ title }}</title>
</head>
<body>
<div id="cellophane" onclick="kub.toggleMenu()"></div>
<header>
<a href="/" class="logo"></a>
<div class="nav-buttons" data-auto-burger="primary">
<ul class="global-nav">
<li>
<a href="#">
{{page.version}} <span class="ui-icon ui-icon-carat-1-s"></span>
</a>
<ul>
{% for version in page.versions %}
<li><a href="{{ version.url }}">{{ version.version }}</a></li>
{% endfor %}
</ul>
</li>
</li>
</ul>
<a href="/docs/" class="button" id="viewDocs" data-auto-burger-exclude>View Documentation</a>
<a href="/docs/hellonode/" class="button" id="tryKubernetes" data-auto-burger-exclude>Try Kubernetes</a>
<button id="hamburger" onclick="kub.toggleMenu()" data-auto-burger-exclude><div></div></button>
</div>
<nav id="mainNav">
<main data-auto-burger="primary">
<div class="nav-box">
<h3><a href="/docs/hellonode/">Get Started</a></h3>
<p>Ready to get your hands dirty? Build a simple Kubernetes cluster that runs "Hello World" for Node.js.</p>
</div>
<div class="nav-box">
<h3><a href="/docs/">Documentation</a></h3>
<p>Learn how to use Kubernetes with the use of walkthroughs, samples, and reference documentation. You can even <a href="/editdocs/" data-auto-burger-exclude>help contribute to the docs</a>!</p>
</div>
<div class="nav-box">
<h3><a href="/community/">Community</a></h3>
<p>If you need help, you can connect with other Kubernetes users and the Kubernetes authors, attend community events, and watch video presentations from around the web.</p>
</div>
<div class="nav-box">
<h3><a href="http://blog.kubernetes.io">Blog</a></h3>
<p>Read the latest news for Kubernetes and the containers space in general, and get technical how-tos hot off the presses.</p>
</div>
</main>
<main data-auto-burger="primary">
<div class="left">
<h5 class="github-invite">Interested in hacking on the core Kubernetes code base?</h5>
<a href="https://github.com/kubernetes/kubernetes" class="button" data-auto-burger-exclude>View On Github</a>
</div>
<div class="right">
<h5 class="github-invite">Explore the community</h5>
<div class="social">
<a href="https://twitter.com/kubernetesio" class="twitter"><span>Twitter</span></a>
<a href="https://github.com/kubernetes/kubernetes" class="github"><span>Github</span></a>
<a href="http://slack.k8s.io/" class="slack"><span>Slack</span></a>
<a href="http://stackoverflow.com/questions/tagged/kubernetes" class="stack-overflow"><span>Stack Overflow</span></a>
<a href="https://groups.google.com/forum/#!forum/kubernetes-users" class="mailing-list"><span>Mailing List</span></a>
<a href="https://calendar.google.com/calendar/embed?src=nt2tcnbtbied3l6gi2h29slvc0%40group.calendar.google.com" class="calendar"><span>Events Calendar</span></a>
</div>
</div>
<div class="clear" style="clear: both"></div>
</main>
</nav>
</header>
+17
View File
@@ -0,0 +1,17 @@
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="shortcut icon" type="image/png" href="/images/favicon.png">
<link href='https://fonts.googleapis.com/css?family=Roboto:400,100,100italic,300,300italic,400italic,500,500italic,700,700italic,900,900italic' rel='stylesheet' type='text/css'>
<link rel="stylesheet" href='https://fonts.googleapis.com/css?family=Roboto+Mono' type='text/css'>
<link rel="stylesheet" href="/css/styles.css"/>
<link rel="stylesheet" href="/css/jquery-ui.min.css">
<link rel="stylesheet" href="/css/sweetalert.css">
{% if page.deprecated %}<link rel="stylesheet" type="text/css" href="/css/deprecation-warning.css">{% endif %}
{% if page.class == "gridPage" %}<link rel="stylesheet" href="/css/gridpage.css">{% endif %}
<script src="/js/jquery-2.2.0.min.js"></script>
<script src="/js/jquery-ui.min.js"></script>
<script src="/js/script.js"></script>
<script src="/js/sweetalert.min.js"></script>
<script src="/js/bootstrap.min.js"></script>
</head>
+67
View File
@@ -0,0 +1,67 @@
<div id="cellophane" onclick="kub.toggleMenu()"></div>
<header>
<a href="/" class="logo"></a>
<div class="nav-buttons" data-auto-burger="primary">
<ul class="global-nav">
<li><a href="/docs/">Documentation</a></li>
<li><a href="http://blog.kubernetes.io/">Blog</a></li>
<li><a href="/community/">Community</a></li>
<li>
<a href="#">
{{page.version}} <span class="ui-icon ui-icon-carat-1-s"></span>
</a>
<ul>
{% for version in page.versions %}
<li><a href="{{ version.url }}">{{ version.version }}</a></li>
{% endfor %}
</ul>
</li>
</li>
</ul>
<!-- <a href="/docs/home" class="button" id="viewDocs" data-auto-burger-exclude>View Documentation</a> -->
<a href="/docs/tutorials/kubernetes-basics/" class="button" id="tryKubernetes" data-auto-burger-exclude>Try Kubernetes</a>
<button id="hamburger" onclick="kub.toggleMenu()" data-auto-burger-exclude><div></div></button>
</div>
<nav id="mainNav">
<main data-auto-burger="primary">
<div class="nav-box">
<h3><a href="/docs/tutorials/stateless-application/hello-minikube/">Get Started</a></h3>
<p>Ready to get your hands dirty? Build a simple Kubernetes cluster that runs "Hello World" for Node.js.</p>
</div>
<div class="nav-box">
<h3><a href="/docs/home/">Documentation</a></h3>
<p>Learn how to use Kubernetes with the use of walkthroughs, samples, and reference documentation. You can even <a href="/editdocs/" data-auto-burger-exclude>help contribute to the docs</a>!</p>
</div>
<div class="nav-box">
<h3><a href="/community/">Community</a></h3>
<p>If you need help, you can connect with other Kubernetes users and the Kubernetes authors, attend community events, and watch video presentations from around the web.</p>
</div>
<div class="nav-box">
<h3><a href="http://blog.kubernetes.io">Blog</a></h3>
<p>Read the latest news for Kubernetes and the containers space in general, and get technical how-tos hot off the presses.</p>
</div>
</main>
<main data-auto-burger="primary">
<div class="left">
<h5 class="github-invite">Interested in hacking on the core Kubernetes code base?</h5>
<a href="https://github.com/kubernetes/kubernetes" class="button" data-auto-burger-exclude>View On Github</a>
</div>
<div class="right">
<h5 class="github-invite">Explore the community</h5>
<div class="social">
<a href="https://twitter.com/kubernetesio" class="twitter"><span>Twitter</span></a>
<a href="https://github.com/kubernetes/kubernetes" class="github"><span>Github</span></a>
<a href="http://slack.k8s.io/" class="slack"><span>Slack</span></a>
<a href="http://stackoverflow.com/questions/tagged/kubernetes" class="stack-overflow"><span>Stack Overflow</span></a>
<a href="https://groups.google.com/forum/#!forum/kubernetes-users" class="mailing-list"><span>Mailing List</span></a>
<a href="https://calendar.google.com/calendar/embed?src=nt2tcnbtbied3l6gi2h29slvc0%40group.calendar.google.com" class="calendar"><span>Events Calendar</span></a>
</div>
</div>
<div class="clear" style="clear: both"></div>
</main>
</nav>
</header>
+327
View File
@@ -0,0 +1,327 @@
;(function () {
var partners = [
{
type: 0,
name: 'CoreOS',
logo: 'core_os',
link: 'https://tectonic.com/',
blurb: 'Tectonic is the enterprise-ready Kubernetes product, by CoreOS. It adds key features to allow you to manage, update, and control clusters in production.'
},
{
type: 0,
name: 'Deis',
logo: 'deis',
link: 'https://deis.com',
blurb: 'Deis the creators of Helm, Workflow, and Steward, helps developers and operators build, deploy, manage and scale their applications on top of Kubernetes.'
},
{
type: 0,
name: 'StackPointCloud',
logo: 'stackpoint',
link: 'https://stackpoint.io',
blurb: 'StackPointCloud builds Stackpoint.io, the universal control plane for Kubernetes Anywhere -- compose and build your own infrastructure as easily as a DigitalOcean droplet at any public cloud provider.'
},
{
type: 0,
name: 'Sysdig Cloud',
logo: 'sys_dig',
link: 'https://sysdig.com/blog/monitoring-kubernetes-with-sysdig-cloud/',
blurb: 'Container native monitoring with deep support for Kubernetes.'
},
{
type: 0,
name: 'Puppet',
logo: 'puppet',
link: 'https://puppet.com/blog/managing-kubernetes-configuration-puppet',
blurb: 'The Puppet module for Kubernetes makes it easy to manage Pods, Replication Controllers, Services and more in Kubernetes, and to build domain-specific interfaces to one\'s Kubernetes configuration.'
},
{
type: 0,
name: 'Citrix',
logo: 'citrix',
link: 'http://wercker.com/workflows/partners/kubernetes/',
blurb: 'Netscaler CPX gives app developers all the features they need to load balance their microservices and containerized apps with Kubernetes.'
},
{
type: 0,
name: 'Cockroach Labs',
logo: 'cockroach_labs',
link: 'https://www.cockroachlabs.com/blog/running-cockroachdb-on-kubernetes/',
blurb: 'CockroachDB is a distributed SQL database whose built-in replication and survivability model pair with Kubernetes to truly make data easy.'
},
{
type: 0,
name: 'Skippbox',
logo: 'skippbox',
link: 'http://www.skippbox.com/tag/products/',
blurb: 'Creator of Cabin the first mobile application for Kubernetes, and kompose. Skippboxs solutions distill all the power of k8s in simple easy to use interfaces.'
},
{
type: 0,
name: 'Weave Works',
logo: 'weave_works',
link: ' https://weave.works/kubernetes',
blurb: 'Weaveworks enables Developers and Dev/Ops teams to easily connect, deploy, secure, manage, and troubleshoot microservices in Kubernetes.'
},
{
type: 0,
name: 'Wercker',
logo: 'wercker',
link: 'http://wercker.com/workflows/partners/kubernetes/',
blurb: 'Wercker automates your build, test and deploy pipelines for launching containers and triggering rolling updates on your Kubernetes cluster. '
},
{
type: 0,
name: 'Rancher',
logo: 'rancher',
link: 'http://rancher.com/kubernetes/',
blurb: 'Rancher is an open-source, production-ready container management platform that makes it easy to deploy and leverage Kubernetes in the enterprise.'
},
{
type: 0,
name: 'Red Hat',
logo: 'redhat',
link: 'https://www.openshift.com/',
blurb: 'Leverage an enterprise Kubernetes platform to orchestrate complex, multi-container apps.'
},
{
type: 0,
name: 'Intel',
logo: 'intel',
link: 'https://tectonic.com/press/intel-coreos-collaborate-on-openstack-with-kubernetes.html',
blurb: 'Powering the GIFEE (Googles Infrastructure for Everyone Else), to run OpenStack deployments on Kubernetes.'
},
{
type: 0,
name: 'ElasticKube',
logo: 'elastickube',
link: 'https://www.ctl.io/elastickube-kubernetes/',
blurb: 'Self-service container management for Kubernetes.'
},
{
type: 0,
name: 'Platform9',
logo: 'platform9',
link: 'https://platform9.com/products/kubernetes/',
blurb: 'Platform9 is the open source-as-a-service company that takes all of the goodness of Kubernetes and delivers it as a managed service.'
},
{
type: 0,
name: 'Datadog',
logo: 'datadog',
link: 'http://docs.datadoghq.com/integrations/kubernetes/',
blurb: 'Full-stack observability for dynamic infrastructure & applications. Includes precision alerting, analytics and deep Kubernetes integrations. '
},
{
type: 0,
name: 'AppFormix',
logo: 'appformix',
link: 'http://www.appformix.com/solutions/appformix-for-kubernetes/',
blurb: 'AppFormix is a cloud infrastructure performance optimization service helping enterprise operators streamline their cloud operations on any Kubernetes cloud. '
},
{
type: 0,
name: 'Crunchy',
logo: 'crunchy',
link: 'http://info.crunchydata.com/blog/advanced-crunchy-containers-for-postgresql',
blurb: 'Crunchy PostgreSQL Container Suite is a set of containers for managing PostgreSQL with DBA microservices leveraging Kubernetes and Helm.'
},
{
type: 0,
name: 'Aqua',
logo: 'aqua',
link: 'http://blog.aquasec.com/security-best-practices-for-kubernetes-deployment',
blurb: 'Deep, automated security for your containers running on Kubernetes.'
},
{
type: 0,
name: 'Canonical',
logo: 'canonical',
link: 'https://jujucharms.com/canonical-kubernetes/',
blurb: 'The Canonical Distribution of Kubernetes enables you to operate Kubernetes clusters on demand on any major public cloud and private infrastructure.'
},
{
type: 0,
name: 'Distelli',
logo: 'distelli',
link: 'https://www.distelli.com/',
blurb: 'Pipelines from your source repositories to your Kubernetes Clusters on any cloud.'
},
{
type: 0,
name: 'Nuage networks',
logo: 'nuagenetworks',
link: 'https://github.com/nuagenetworks/nuage-kubernetes',
blurb: 'The Nuage SDN platform provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.'
},
{
type: 0,
name: 'Sematext',
logo: 'sematext',
link: 'https://sematext.com/kubernetes/',
blurb: 'Logging & Monitoring: Automatic collection and processing of Metrics, Events and Logs for auto-discovered pods and Kubernetes nodes.'
},
{
type: 0,
name: 'Diamanti',
logo: 'diamanti',
link: 'https://www.diamanti.com/products/',
blurb: 'Diamanti deploys containers with guaranteed performance using Kubernetes in the first hyperconverged appliance purpose built for containerized applications.'
},
{
type: 0,
name: 'Apprenda',
logo: 'apprenda',
link: 'https://apprenda.com/kubernetes-support/',
blurb: 'Apprenda creates and supports modern, enterprise-ready application platforms for both cloud native and traditional application workloads.'
},
{
type: 0,
name: 'Aporeto',
logo: 'aporeto',
link: 'https://aporeto.com/trireme',
blurb: 'Aporeto makes cloud-native applications secure by default without impacting developer velocity and works at any scale, on any cloud.'
},
{
type: 0,
name: 'Giant Swarm',
logo: 'giant_swarm',
link: 'https://giantswarm.io',
blurb: 'Giant Swarm provides fully-managed Kubernetes Clusters in your location of choice, so you can focus on your product.'
},
{
type: 0,
name: 'Mirantis',
logo: 'mirantis',
link: 'https://content.mirantis.com/Containerizing-OpenStack-on-Kubernetes-Video-Landing-Page.html',
blurb: 'Mirantis builds and manages private clouds with open source software such as OpenStack, deployed as containers orchestrated by Kubernetes.'
},
{
type: 0,
name: 'Kubernetic',
logo: 'kubernetic',
link: 'https://kubernetic.com/',
blurb: 'Kubernetic is a Kubernetes Desktop client that simplifies and democratizes cluster management for DevOps.'
},
{
type: 1,
name: 'Apprenda',
logo: 'apprenda',
link: 'https://apprenda.com/kubernetes-support/',
blurb: 'Apprenda offers flexible and wide range of support plans for pure play Kubernetes on your choice of infrastructure, cloud provider and operating system.'
},
{
type: 1,
name: 'Reactive Ops',
logo: 'reactive_ops',
link: 'https://www.reactiveops.com/kubernetes/',
blurb: 'ReactiveOps has written automation on best practices for infrastructure as code on GCP & AWS using Kubernetes, helping you build and maintain a world-class infrastructure at a fraction of the price of an internal hire.'
},
{
type: 1,
name: 'Livewyer',
logo: 'livewyer',
link: 'https://livewyer.io/services/kubernetes-experts/',
blurb: 'Kubernetes experts that on-board applications and empower IT teams to get the most out of containerised technology.'
},
{
type: 1,
name: 'Deis',
logo: 'deis',
link: 'https://deis.com/services/',
blurb: 'Deis provides professional services and 24x7 operational support for any Kubernetes cluster managed by our global cluster operations team.'
},
{
type: 1,
name: 'StackPointCloud',
logo: 'stackpoint',
link: 'https://stackpoint.io',
blurb: 'StackPointCloud offers a wide range of support plans for managed Kubernetes clusters built through its universal control plane for Kubernetes Anywhere.'
},
{
type: 1,
name: 'Samsung SDS',
logo: 'samsung_sds',
link: 'http://www.samsungsdsa.com/cloud-infrastructure_kubernetes',
blurb: 'Samsung SDSs Cloud Native Computing Team offers expert consulting across the range of technical aspects involved in building services targeted at a Kubernetes cluster.'
},
{
type: 1,
name: 'Container Solutions',
logo: 'container_solutions',
link: 'http://container-solutions.com/resources/kubernetes/',
blurb: 'Container Solutions is a premium software consultancy that focuses on programmable infrastructure, offering our expertise in software development, strategy and operations to help you innovate at speed and scale.'
},
{
type: 1,
name: 'Jetstack',
logo: 'jetstack',
link: 'https://www.jetstack.io/',
blurb: 'Jetstack is an organisation focused entirely on Kubernetes. They will help you to get the most out of Kubernetes through expert professional services and open source tooling. Get in touch, and accelerate your project.'
},
{
type: 0,
name: 'Tigera',
logo: 'tigera',
link: 'http://docs.projectcalico.org/v1.5/getting-started/kubernetes/',
blurb: 'Tigera builds high performance, policy driven, cloud native networking solutions for Kubernetes.'
},
{
type: 1,
name: 'Skippbox',
logo: 'skippbox',
link: 'http://www.skippbox.com/services/',
blurb: 'Skippbox brings its Kubernetes expertise to help companies embrace Kubernetes on their way to digital transformation. Skippbox offers both professional services and expert training.'
},
{
type: 1,
name: 'Harbur',
logo: 'harbur',
link: 'https://harbur.io/',
blurb: 'Based in Barcelona, Harbur is a consulting firm that helps companies deploy self-healing solutions empowered by Container technologies'
},
{
type: 1,
name: 'Endocode',
logo: 'endocode',
link: 'https://endocode.com/kubernetes/',
blurb: 'Endocode practices and teaches the open source way. Kernel to cluster - Dev to Ops. We offer Kubernetes trainings, services and support.'
}
]
var isvContainer = document.getElementById('isvContainer')
var servContainer = document.getElementById('servContainer')
var sorted = partners.sort(function (a, b) {
if (a.name > b.name) return 1
if (a.name < b.name) return -1
return 0
})
sorted.forEach(function (obj) {
var box = document.createElement('div')
box.className = 'partner-box'
var img = document.createElement('img')
img.src = '/images/square-logos/' + obj.logo + '.png'
var div = document.createElement('div')
var p = document.createElement('p')
p.textContent = obj.blurb
var link = document.createElement('a')
link.href = obj.link
link.target = '_blank'
link.textContent = 'Learn more'
div.appendChild(p)
div.appendChild(link)
box.appendChild(img)
box.appendChild(div)
var container = obj.type ? servContainer : isvContainer
container.appendChild(box)
})
})();
+94
View File
@@ -0,0 +1,94 @@
h5 {
font-size: 18px;
line-height: 1.5em;
margin-bottom: 2em;
}
#usersGrid a {
display: inline-block;
background-color: #f9f9f9;
}
#isvContainer, #servContainer {
position: relative;
width: 100%;
display: flex;
justify-content: space-between;
flex-wrap: wrap;
}
#isvContainer {
margin-bottom: 80px;
}
.partner-box {
position: relative;
width: 47%;
max-width: 48%;
min-width: 48%;
margin-bottom: 20px;
padding: 20px;
flex: 1;
display: flex;
justify-content: space-between;
align-items: flex-start;
}
.partner-box img {
background-color: #f9f9f9;
}
.partner-box > div {
margin-left: 30px;
}
.partner-box a {
color: #3576E3;
}
@media screen and (max-width: 1024px) {
.partner-box {
flex-direction: column;
justify-content: flex-start;
}
.partner-box > div {
margin: 20px 0 0;
}
}
@media screen and (max-width: 568px) {
#isvContainer, #servContainer {
justify-content: center;
}
.partner-box {
flex-direction: column;
justify-content: flex-start;
width: 100%;
max-width: 100%;
min-width: 100%;
}
.partner-box > div {
margin: 20px 0 0;
}
}
@media screen and (max-width: 568px) {
#isvContainer, #servContainer {
justify-content: center;
}
.partner-box {
flex-direction: column;
justify-content: flex-start;
width: 100%;
max-width: 100%;
min-width: 100%;
}
.partner-box > div {
margin: 20px 0 0;
}
}
+17
View File
@@ -0,0 +1,17 @@
{% assign tabsraw = tabspec | newline_to_br | split: '<br />' %}
{% assign tabsetname = tabsraw[0] %}
<script>$(function(){$("#{{tabsetname}}").tabs();});</script>
<div id="{{tabsetname}}">
<ul>{% for tab in tabsraw offset:1 %}{% assign thisTab = tab | split: ',' %}
<li><a href="#{{ thisTab[0] | strip | handleize }}">{{ thisTab[0] | strip}}</a></li>{% endfor %}
</ul>
{% for tab in tabsraw offset:1 %}
{% assign thisTab = tab | split: ',' %}
{% assign tabLang=thisTab[1] %}
{% assign tabFile=thisTab[2] %}
{% assign tabGHLink=thisTab[3] %}
<div id="{{ thisTab[0] | strip | handleize }}">
{% include code.html language=tabLang file=tabFile ghlink=tabGHLink %}
</div>
{% endfor %}
</div>
+4
View File
@@ -0,0 +1,4 @@
You need to have a Kubernetes cluster, and the kubectl command-line tool must
be configured to communicate with your cluster. If you do not already have a
cluster, you can create one by using
[Minikube](/docs/getting-started-guides/minikube).
+16
View File
@@ -0,0 +1,16 @@
### ERROR: You must define a <span style="font-family: monospace">`{{ include.missing_block }}`</span> block
{: style="color:red" }
This template requires that you provide text that {{ include.purpose }}. The text in this block will
be displayed under the heading **{{ include.heading }}**.
To get rid of this message and take advantage of this template, define the `{{ include.missing_block }}`
variable and populate it with content.
```liquid
{% raw %}{%{% endraw %} capture {{ include.missing_block }} {% raw %}%}{% endraw %}
Text that {{ include.purpose }}.
{% raw %}{%{% endraw %} endcapture {% raw %}%}{% endraw %}
```
<!-- TEMPLATE_ERROR -->
+88
View File
@@ -0,0 +1,88 @@
{% if concept %}<!-- check for this before going any further; if not present, skip to else at bottom -->
# Overview of {{concept}}s
{% if what_is %}
### What is a {{ concept }}?
{{ what_is }}
{% else %}
{% include templates/_errorthrower.md missing_block='what_is' heading='What is a (Concept)?' purpose='explains what this concept is and its purpose.' %}
{% endif %}
{% if when_to_use %}
### When to use {{ concept }}s
{{ when_to_use }}
{% else %}
{% include templates/_errorthrower.md missing_block='when_to_use' heading='When to use (Concept)' purpose='explains when to use this object.' %}
{% endif %}
{% if when_not_to_use %}
### When not to use {{ concept }}s
{{ when_not_to_use }}
{% else %}
{% include templates/_errorthrower.md missing_block='when_not_to_use' heading='When not to use (Concept)' purpose='explains when not to use this object.' %}
{% endif %}
{% if status %}
### {{ concept }} status
{{ status }}
{% else %}
{% include templates/_errorthrower.md missing_block='status' heading='Retrieving status for a (Concept)' purpose='explains how to retrieve a status description for this object.' %}
{% endif %}
{% if usage %}
#### Usage
{{ usage }}
{% else %}
{% include templates/_errorthrower.md missing_block='usage' heading='Usage' purpose='shows the most basic, common use case for this object, in the form of a code sample, command, etc, using tabs to show multiple approaches' %}
{% endif %}
<!-- continuing the "if concept" if/then: -->
{% else %}
### ERROR: You must define a "concept" variable
{: style="color:red" }
This template requires a variable called `concept` that is simply the name of the
concept for which you are giving an overview. This will be displayed in the
headings for the document.
To get rid of this message and take advantage of this template, define `concept`:
```liquid
{% raw %}{% assign concept="Replication Controller" %}{% endraw %}
```
Complete this task, then we'll walk you through preparing the rest of the document.
{% endif %}
+32
View File
@@ -0,0 +1,32 @@
{% if overview %}
{{ overview }}
{% else %}
{% include templates/_errorthrower.md missing_block='overview' purpose='provides an overview of this concept.' %}
{% endif %}
* TOC
{:toc}
{% if body %}
{{ body }}
{% else %}
{% include templates/_errorthrower.md missing_block='body' purpose='supplies the body of the page content.' %}
{% endif %}
{% if whatsnext %}
### What's next
{{ whatsnext }}
{% endif %}
+37
View File
@@ -0,0 +1,37 @@
{% if command %}
# {% if site.data.kubectl[command].name != "kubectl" %}kubectl {% endif %}{{ site.data.kubectl[command].name }}
{{ site.data.kubectl[command].synopsis }}
## Description
{{ site.data.kubectl[command].description }}
{% if site.data.kubectl[command].options %}
## Options
| Option | Shorthand | Default Value | Usage |
|--------------------|---------------|-------|{% for option in site.data.kubectl[command].options %}
| `{{option.name | strip}}` | {% if option.shorthand %}`{{ option.shorthand | strip }}`{% endif %} | {% if option.default_value %}`{{option.default_value| strip}}`{% endif %} | {% if option.usage %}{{option.usage| strip | replace:'|',', '}}{% endif %} |{% endfor %}
{% endif %}
{% if site.data.kubectl[command].inherited_options %}
## Inherited Options
| Option | Shorthand | Default Value | Usage |
|--------------------|---------------|-------|{% for option in site.data.kubectl[command].inherited_options %}
| `{{option.name | strip}}` | {% if option.shorthand %}`{{ option.shorthand | strip }}`{% endif %} | {% if option.default_value %}`{{option.default_value| strip}}`{% endif %} | {% if option.usage %}{{option.usage| strip | replace:'|',', '}}{% endif %} |{% endfor %}
{% endif %}
## See also
{% for seealso in site.data.kubectl[command].see_also %}
- [`{{ seealso }}`](/docs/kubectl/{% if seealso != "kubectl" %}kubectl_{{seealso}}{% endif %})
{% endfor %}
{% else %}
{% include templates/_errorthrower.md missing_block='command' heading='kubectl (command)' purpose='names the kubectl command, so that the appropriate YAML file (from _data/kubectl) can be transformed into a page.' %}
{% endif %}
+121
View File
@@ -0,0 +1,121 @@
{% if page.cards %}<!-- check for this before going any further; if not present, skip to else at bottom -->
<style>
h2, h3, h4 {
border-bottom: 0px !important;
font-size: 22px !important;
padding-bottom: 20px !important;
}
.colContainer {
padding-top:2px;
padding-left: 2px;
overflow: auto;
}
#samples a {
color: #000;
}
.col3rd {
display: block;
float: left;
margin-right: 30px;
margin-bottom: 30px;
overflow: hidden;
}
.col3rd h3, .col2nd h3 {
margin-bottom: 0px !important;
}
.col3rd .button, .col2nd .button {
margin-top: 20px;
border-radius: 2px;
}
.col3rd p, .col2nd p {
margin-left: 2px;
}
.col2nd {
display: block;
width: 400px;
float: left;
margin-right: 30px;
margin-bottom: 30px;
overflow: hidden;
}
.shadowbox {
width: 250px;
display: inline;
float: left;
text-transform: none;
font-weight: bold;
text-overflow: ellipsis;
overflow: hidden;
line-height: 24px;
position: relative;
display: block;
cursor: pointer;
box-shadow: 0 2px 2px rgba(0,0,0,.24),0 0 2px rgba(0,0,0,.12);
border-radius: 5px;
background: #fff;
transition: all .3s;
padding: 16px;
margin: 0 16px 16px 0;
text-decoration: none;
letter-spacing: .01em;
height: 220px;
}
.shadowbox img {
min-width: 100px;
max-width: 100px;
max-height: 50px;
margin-right: 5px;
margin-bottom: 5px;
float: left;
}
</style>
<div class="colContainer">
{% for card in page.cards %}{% if card.title %}
<div class="col3rd shadowbox">
<h3>{{card.title}}</h3>
<p>{% if card.image %}<img src="{{card.image}}">{% endif %}{{card.description}}</p>
</div>
{% endif %}{% endfor %}
</div>
{% else %}
### ERROR: You must define "cards" front-matter YAML
{: style="color:red" }
This template requires that you insert YAML at the top of your document
that defines the "cards" you'd like to display on the page. The cards will
render in clickable boxes.
To get rid of this message and take advantage of this template, define `cards`:
```yaml
---
cards:
- progression: no
- card:
title: Mean Stack
image: /docs/meanstack/image_0.png
description: Lorem ipsum dolor it verberum.
- card:
title: Guestbook + Redis
image: /images/docs/redis.svg
description: Lorem ipsum dolor it verberum.
- card:
title: Cloud Native Cassandra
image: /images/docs/cassandra.svg
description: Lorem ipsum dolor it verberum.
- card:
title: WordPress + MySQL
image: /images/docs/wordpress.svg
description: Lorem ipsum dolor it verberum.
---
```
**Note:** If `progression` is set to `yes` then a "Start Here!" icon will be
placed on the first card and arrows suggesting linear reading will be overlayed
between the other cards, telling the reader that they should explore the content
in a certain order.
{% endif %}
+55
View File
@@ -0,0 +1,55 @@
{% if overview %}
{{ overview }}
{% else %}
{% include templates/_errorthrower.md missing_block='overview' purpose='states, in one or two sentences, the purpose of this document' %}
{% endif %}
* TOC
{: toc}
{% if prerequisites %}
### Before you begin
{{ prerequisites }}
{% else %}
{% include templates/_errorthrower.md missing_block='prerequisites' heading='Before you begin' purpose='lists action prerequisites and knowledge prerequisites' %}
{% endif %}
{% if steps %}
{{ steps }}
{% else %}
{% include templates/_errorthrower.md missing_block='steps' purpose='lists a sequence of numbered steps that accomplish the task.' %}
{% endif %}
{% if discussion %}
{{ discussion }}
{% else %}
{% endif %}
{% if whatsnext %}
### What's next
{{ whatsnext }}
{% endif %}
+68
View File
@@ -0,0 +1,68 @@
{% if overview %}
{{ overview }}
{% else %}
{% include templates/_errorthrower.md missing_block='overview' purpose='states, in one or two sentences, the purpose of this document' %}
{% endif %}
* TOC
{: toc}
{% if objectives %}
### Objectives
{{ objectives }}
{% else %}
{% include templates/_errorthrower.md missing_block='objectives' heading='Objectives' purpose='lists the objectives for this tutorial.' %}
{% endif %}
{% if prerequisites %}
### Before you begin
{{ prerequisites }}
{% else %}
{% include templates/_errorthrower.md missing_block='prerequisites' heading='Before you begin' purpose='lists action prerequisites and knowledge prerequisites' %}
{% endif %}
{% if lessoncontent %}
{{ lessoncontent }}
{% else %}
{% include templates/_errorthrower.md missing_block='lessoncontent' purpose='provides the lesson content for this tutorial.' %}
{% endif %}
{% if cleanup %}
### Cleaning up
{{ cleanup }}
{% endif %}
{% if whatsnext %}
### What's next
{{ whatsnext }}
{% endif %}
+1
View File
@@ -0,0 +1 @@
{% for item in tree %}{% if item.section %}{% assign tree = item.section %}{% include tocsearch.html %}{% else %}{% if item.path == page.url %}{% assign foundTOC = thistoc %}{% assign title = item.title %}{% break %}{% endif %}{% endif %}{% endfor %}
+6
View File
@@ -0,0 +1,6 @@
{% for item in tree %}{% if item.section %}
<div class="item" data-title="{{ item.title }}">
<div class="container">{% assign tree = item.section %}{% include tree.html %}
</div>
</div>{% else %}{% assign prefix = item.path | slice: 0, 4 %}{% if prefix == "http" %}{% assign target=" target='_blank'" %}{% else %}{% assign target="" %}{% endif %}
<a class="item" data-title="{{ item.title }}" href="{{ item.path }}"{{ target }}></a>{% endif %}{% endfor %}
File diff suppressed because it is too large Load Diff
File diff suppressed because it is too large Load Diff
+7806
View File
File diff suppressed because it is too large Load Diff
+32321
View File
File diff suppressed because it is too large Load Diff
File diff suppressed because it is too large Load Diff
File diff suppressed because it is too large Load Diff
+8087
View File
File diff suppressed because it is too large Load Diff
+32451
View File
File diff suppressed because it is too large Load Diff
+84
View File
@@ -0,0 +1,84 @@
{% for current_toc in site.tocs %}
{% if found_toc %}
{% break %}
{% else %}
{% assign toc=site.data[current_toc] %}
{% include tocsearch.html tree=toc.toc toc=toc %}
{% endif %}
{% endfor %}
<!Doctype html>
<html id="docs" class="{{ toc.bigheader }}">
{% include head.html %}
<body>
{% include header.html %}
<!-- HERO -->
<section id="hero" class="light-text">
<h1>{{ toc.bigheader }}</h1>
<h5>{{ toc.abstract }}</h5>
<div id="vendorStrip" class="light-text">
<ul>
<li><a href="/docs/" {% if toc.bigheader == "Kubernetes Documentation" %}class="YAH"{% endif %}>DOCS HOME</a></li>
<li><a href="/docs/user-guide/" {% if toc.bigheader == "Guides" %}class="YAH"{% endif %}>GUIDES</a></li>
<li><a href="/docs/tutorials/" {% if toc.bigheader == "Tutorials" %}class="YAH"{% endif %}>TUTORIALS</a></li>
<li><a href="/docs/tasks/" {% if toc.bigheader == "Tasks" %}class="YAH"{% endif %}>TASKS</a></li>
<li><a href="/docs/concepts/" {% if toc.bigheader == "Concepts" %}class="YAH"{% endif %}>CONCEPTS</a></li>
<li><a href="/docs/reference/" {% if toc.bigheader == "Reference Documentation" %}class="YAH"{% endif %}>REFERENCE</a></li>
<li><a href="/docs/tools/" {% if toc.bigheader == "Tools" %}class="YAH"{% endif %}>TOOLS</a></li>
<li><a href="/docs/samples/" {% if toc.bigheader == "Samples" %}class="YAH"{% endif %}>SAMPLES</a></li>
<li><a href="/docs/troubleshooting/" {% if toc.bigheader == "Support" %}class="YAH"{% endif %}>SUPPORT</a></li>
</ul>
<div id="searchBox">
<input type="text" id="search" placeholder="Search" onkeydown="if (event.keyCode==13) window.location.replace('/docs/search/?q=' + this.value)" autofocus="autofocus">
</div>
</div>
</section>
{% include deprecation-warning.html %}
<section id="encyclopedia">
<div id="docsToc">
<div class="pi-accordion">
{% if toc.bigheader != "Kubernetes Documentation" %}
{% include tree.html tree=toc.toc %}
{% endif %}
</div> <!-- /pi-accordion -->
<button class="push-menu-close-button" onclick="kub.toggleToc()"></button>
</div> <!-- /docsToc -->
<div id="docsContent">
<p><a href="/editdocs#{{ page.path }}" id="editPageButton">Edit This Page</a></p>
{% unless page.notitle %}
<h1>{{ page.title }}</h1>
{% endunless %}
{{ content }}
<p><a href=""><img src="https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/{{ page.path }}?pixel" alt="Analytics" /></a></p>
{% if page.url != "/404.html" and page.url != "/docs/search/" %}
<script type="text/javascript">
PDRTJS_settings_8345992 = {
"id" : "8345992",
"unique_id" : "{{ page.url }}",
"title" : "{{ page.title }}",
"permalink" : "http://kubernetes.github.io{{ page.url }}"
};
(function(d,c,j){if(!document.getElementById(j)){var pd=d.createElement(c),s;pd.id=j;pd.src=('https:'==document.location.protocol)?'https://polldaddy.com/js/rating/rating.js':'http://i0.poll.fm/js/rating/rating.js';s=document.getElementsByTagName(c)[0];s.parentNode.insertBefore(pd,s);}}(document,'script','pd-rating-js'));
</script>
<a href="" onclick="window.open('https://github.com/kubernetes/kubernetes.github.io/issues/new?title=Issue%20with%20' +
window.location.pathname)" class="button issue">Create an Issue</a>
<a href="/editdocs#{{ page.path }}" class="button issue">Edit this Page</a>
{% endif %}
</div>
</section>
{% include footer.html %}
{% include footer-scripts.html %}
</body>
</html>
File diff suppressed because it is too large Load Diff
+199
View File
@@ -0,0 +1,199 @@
/* Default gh-pages-blog css from https://github.com/thedereck/gh-pages-blog/blob/master/css/syntax.css */
.highlight br
display: none
.highlight
background: #ffffff
.highlight .c
color: #999988
font-style: italic
.highlight .err
color: #a61717
background-color: #e3d2d2
.highlight .k
font-weight: bold
.highlight .o
font-weight: bold
.highlight .cm
color: #999988
font-style: italic
.highlight .cp
color: #999999
font-weight: bold
.highlight .c1
color: #999988
font-style: italic
.highlight .cs
color: #999999
font-weight: bold
font-style: italic
.highlight .gd
color: #000000
background-color: #ffdddd
.highlight .gd .x
color: #000000
background-color: #ffaaaa
.highlight .ge
font-style: italic
.highlight .gr
color: #aa0000
.highlight .gh
color: #999999
.highlight .gi
color: #000000
background-color: #ddffdd
.highlight .gi .x
color: #000000
background-color: #aaffaa
.highlight .go
color: #888888
.highlight .gp
color: #555555
.highlight .gs
font-weight: bold
.highlight .gu
color: #aaaaaa
.highlight .gt
color: #aa0000
.highlight .kc
font-weight: bold
.highlight .kd
font-weight: bold
.highlight .kp
font-weight: bold
.highlight .kr
font-weight: bold
.highlight .kt
color: #445588
font-weight: bold
.highlight .m
color: #009999
.highlight .s
color: #d14
.highlight .na
color: #008080
.highlight .nb
color: #0086B3
.highlight .nc
color: #445588
font-weight: bold
.highlight .no
color: #008080
.highlight .ni
color: #800080
.highlight .ne
color: #990000
font-weight: bold
.highlight .nf
color: #990000
font-weight: bold
.highlight .nn
color: #555555
.highlight .nt
color: #000080
.highlight .nv
color: #008080
.highlight .ow
font-weight: bold
.highlight .w
color: #bbbbbb
.highlight .mf
color: #009999
.highlight .mh
color: #009999
.highlight .mi
color: #009999
.highlight .mo
color: #009999
.highlight .sb
color: #d14
.highlight .sc
color: #d14
.highlight .sd
color: #d14
.highlight .s2
color: #d14
.highlight .se
color: #d14
.highlight .sh
color: #d14
.highlight .si
color: #d14
.highlight .sx
color: #d14
.highlight .sr
color: #009926
.highlight .s1
color: #d14
.highlight .ss
color: #990073
.highlight .bp
color: #999999
.highlight .vc
color: #008080
.highlight .vg
color: #008080
.highlight .vi
color: #008080
.highlight .il
color: #009999
+5 -31
View File
@@ -3,15 +3,6 @@ $vendor-strip-height: 44px
$video-section-height: 550px
@media screen and (min-width: 1025px)
#hamburger
display: none
ul.global-nav
display: inline-block
#docs #vendorStrip #searchBox:before
top: 15px
#vendorStrip
height: $vendor-strip-height
line-height: $vendor-strip-height
@@ -49,7 +40,7 @@ $video-section-height: 550px
#searchBox
float: right
width: 250px
width: 30%
#search
vertical-align: middle
@@ -74,7 +65,7 @@ $video-section-height: 550px
#encyclopedia
padding: 50px 50px 100px 100px
padding: 50px 50px 20px 20px
clear: both
#docsToc
@@ -98,14 +89,6 @@ $video-section-height: 550px
main
max-width: $main-max-width
header, #vendorStrip, #encyclopedia, #hero h1, #hero h5, #docs #hero h1, #docs #hero h5,
#community #hero h1, .gridPage #hero h1, #community #hero h5, .gridPage #hero h5
padding-left: 100px
padding-right: 100px
#vendorStrip
padding-right: 10px
#home
section, header, footer
main
@@ -138,7 +121,7 @@ $video-section-height: 550px
#video
height: $video-section-height
position: relative
background-image: url(../images/kub_video_banner_box.jpg)
background-image: url(../images/kub_video_thm.jpg)
background-position: center center
background-size: cover
@@ -293,13 +276,13 @@ $video-section-height: 550px
text-align: left
h1
padding: 20px 100px
padding: 20px
#tryKubernetes
width: auto
background-color: $blue
padding: 0 20px
@@ -312,12 +295,3 @@ $video-section-height: 550px
div
width: 24%
min-height: 260px
@media screen and (min-width: 1300px)
#vendorStrip
padding-right: 100px
@media screen and (min-width: 456px)
#vendorStrip
li + li
margin-left: 20px
-6
View File
@@ -1,6 +0,0 @@
---
title: "{{ replace .Name "-" " " | title }}"
date: {{ .Date }}
draft: true
---
+100
View File
@@ -0,0 +1,100 @@
---
title: Case Studies
---
<!Doctype html>
<html id="caseStudies" class="gridPage">
{% include head-header.html %}
<section id="hero" class="light-text">
<h1>Kubernetes User Case Studies</h1>
<h5>A collection of users running Kubernetes in production.</h5>
</section>
<section id="mainContent">
<main>
<div class="content">
<div class="case-studies">
<div class="case-study">
<img src="/images/case_studies/pearson.png" alt="Pearson">
<p class="quote">“We chose Kubernetes because of its flexibility, ease of management and the way it improves our engineers productivity.”</p>
<!--<p class="attrib">— Chris Jackson, Director for Cloud Product Engineering, Pearson</p>-->
<a href="./pearson/">Read about Pearson</a>
</div>
<div class="case-study">
<img src="/images/case_studies/wikimedia.png" alt="Wikimedia">
<p class="quote">“With Kubernetes, were simplifying our environment and making it easier for developers to build the tools that make wikis run better.”</p>
<!--<p class="attrib">— Yuvi Panda, Operations Engineer, Wikimedia Foundation</p>-->
<a href="./wikimedia/">Read about Wikimedia</a>
</div>
<div class="case-study">
<img src="/images/case_studies/ebay.png" alt="eBay">
<p class="quote">Inside eBays shift to Kubernetes and containers atop OpenStack</p>
<a href="http://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/">Read about eBay</a>
</div>
<div class="case-study">
<img src="/images/case_studies/box.png" alt="box">
<p class="quote">Kubernetes at Box: Microservices at Maximum Velocity</p>
<a href="https://blog.box.com/blog/kubernetes-box-microservices-maximum-velocity/">Read about Box</a>
</div>
</div>
</div>
</main>
</section>
<section id="video">
<main>
<!--<div>-->
<!--<h3>“I dont want to deploy software the old way ever again”</h3>-->
<!--<p class="attrib">— Dylan Carney, Lead Software Engineer, Zulily</p>-->
<!--<img src="/images/case_studies/zulily.png" id="zulilyLogo" alt="zulily">-->
<!--</div>-->
<!--<div><button onclick="kub.showVideo()"><img src="/images/case_studies/video_thumb.jpg" alt="Zulily video"><h6>Kubernetes at zulily</h6></button></div>-->
<div>
<!--<h3>SAP</h3>-->
<h3>SAP's OpenStack, running on Kubernetes in production</h3>
<img src="/images/case_studies/sap_small.png" id="zulilyLogo" alt="SAP">
</div>
<div><button onclick="kub.showVideo()"><img src="/images/case_studies/video_thumb1.png" alt="SAP video"><h6>Kubernetes at SAP</h6></button></div>
</main>
</section>
<section id="users">
<main>
<h3>Kubernetes Users</h3>
<div id="usersGrid">
<a target="_blank" href="https://www.youtube.com/watch?v=P5qfyv_zGcU"><img src="/images/case_studies/nyt.png" alt="New York Times"></a>
<a target="_blank" href="https://openai.com/blog/infrastructure-for-deep-learning"><img src="/images/case_studies/openai.png" alt="OpenAI"></a>
<a target="_blank" href="http://blogs.wsj.com/cio/2016/02/24/big-changes-in-goldmans-software-emerge-from-small-containers/"><img src="/images/case_studies/gs.png" alt="Goldman Sachs"></a>
<a target="_blank" href="https://youtu.be/4gyeixJLabo"><img src="/images/case_studies/sap.png" alt="SAP"></a>
<a target="_blank" href="http://www.nextplatform.com/2016/05/24/samsung-experts-put-kubernetes-paces/"><img src="/images/case_studies/sds.png" alt="Samsung SDS"></a>
<a target="_blank" href="http://thenewstack.io/wepay-kubernetes-changed-business/"><img src="/images/case_studies/wepay.png" alt="WePay"></a>
<a target="_blank" href="https://www.youtube.com/watch?v=5378N5iLb2Q"><img src="/images/case_studies/soundcloud.png" alt="SoundCloud"></a>
<a target="_blank" href="https://www.youtube.com/watch?v=F3iMkz_NSvU"><img src="/images/case_studies/homeoffice.png" alt="UK Home Office"></a>
<a target="_blank" href="http://searchitoperations.techtarget.com/news/450297178/Tech-firms-roll-out-Kubernetes-in-production"><img src="/images/case_studies/concur.png" alt="Concur"></a>
<a target="_blank" href="http://www.nextplatform.com/2015/08/04/amadeus-takes-off-with-containers-and-clouds/"><img src="/images/case_studies/amadeus.png" alt="Amadeus"></a>
<a target="_blank" href="http://superuser.openstack.org/articles/how-ancestry-com-s-open-source-strategy-combines-kubernetes-and-openstack"><img src="/images/case_studies/ancestry.png" alt="Ancestry.com"></a>
<a target="_blank" href="https://cloud.google.com/customers/ccp-games/"><img src="/images/case_studies/ccp.png" alt="CCP Games"></a>
<a target="_blank" href="https://www.openstack.org/videos/video/running-kubernetes-on-openstack-at-liveperson"><img src="/images/case_studies/liveperson.png" alt="LivePerson"></a>
<a target="_blank" href="http://techblog.yahoo.co.jp/infrastructure/os_n_k8s/"><img src="/images/case_studies/yahooJapan_logo.png" alt="Yahoo! Japan"></a>
<a target="_blank" href="https://blog.box.com/blog/kubernetes-box-microservices-maximum-velocity/"><img src="/images/case_studies/box_logo.png" alt="Box"></a>
<a href="./wikimedia/"><img src="/images/case_studies/wikimedia_logo.png" alt="Wikimedia"></a>
<a href="./pearson/"><img src="/images/case_studies/pearson_logo.png" alt="Pearson"></a>
<a target="_blank" href="#" onclick="event.preventDefault(); kub.showVideo()"><img src="/images/case_studies/zulily_logo.png" alt="zulily"></a>
<a target="_blank" href="http://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/"><img src="/images/case_studies/ebay_logo.png" alt="Ebay"></a>
<a target="_blank" href="https://docs.google.com/a/google.com/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform" class="tell-your-story"><img src="/images/case_studies/story.png" alt="Tell your story"></a>
</div>
</main>
</section>
<div id="videoPlayer">
<!--<iframe data-url="https://www.youtube.com/watch?v=B0_5Nms8sD0" frameborder="0" allowfullscreen></iframe>-->
<iframe data-url="https://www.youtube.com/embed/4gyeixJLabo?autoplay=1" frameborder="0" allowfullscreen></iframe>
<button id="closeButton"></button>
</div>
{% include footer.html %}
{% include case-study-styles.html %}
</body>
</html>
+88
View File
@@ -0,0 +1,88 @@
---
title: Pearson Case Study
---
<!Doctype html>
<html id="caseStudies" class="gridPage">
{% include head-header.html %}
<section id="hero" class="light-text">
<h1> Pearson Case Study</h1>
</section>
<section id="mainContent">
<main>
<div class="content">
<h3 id="caseStudyTitle">Using Kubernetes to reinvent the worlds largest educational company</h3>
<p>
Pearson, the worlds education company, serving 75 million learners worldwide, set a goal to more than double that number to 200 million by 2025. A key part of this growth is in digital learning experiences, and that requires an infrastructure platform that is able to scale quickly and deliver products to market faster. So Pearsons Cloud Technology team chose Kubernetes to help build a platform to meet the business requirements. </p>
<div class="feature">
<img src="/images/case_studies/pearson.png" alt="Pearson">
<p class="quote">
“To transform our infrastructure, we had to think beyond simply enabling automated provisioning, we realized we had to build a platform that would allow Pearson developers to build manage and deploy applications in a completely different way. We chose Kubernetes because of its flexibility, ease of management and the way it would improve our engineers productivity.” </p>
<p class="attrib">— Chris Jackson, Director for Cloud Product Engineering, Pearson</p>
</div>
</div>
</main>
</section>
<section class="bullets">
<main>
<div class="content">
<div class="bullet">
<h4>Challenges:</h4>
<ul>
<li>Pearson had difficulty in scaling and adapting to the growing online audience. They wanted to build and deliver content primarily over the web.</li>
</ul>
</div>
<div class="bullet">
<h4>Why Kubernetes:</h4>
<ul>
<li>Kubernetes will allow Pearsons teams to develop their apps in a consistent manner, saving time and minimizing complexity.</li>
</ul>
</div>
<div class="bullet">
<h4>Approach:</h4>
<ul>
<li>Build a centralized platform for use across the entire enterprise</li>
<li>Use container technology as the core of the platform</li>
<li>Deploy Kubernetes to manage the platform</li>
</ul>
</div>
<div class="bullet">
<h4>Results:</h4>
<ul>
<li>Pearson is building an enterprise-wide platform for delivering innovative, web-based educational content. They expect engineers productivity to increase by up to 20 percent.</li>
</ul>
</div>
</div>
</main>
</section>
<section class="details">
<main>
<div class="content">
<h4>Kubernetes powers a comprehensive developer experience</h4>
<p>Pearson wanted to use as much open source technology as possible for the platform given that it provides both technical and commercial benefits over the duration of the project. Jackson says, “Building an infrastructure platform based on open source technology in Pearson was a no-brainer, the sharing of technical challenges and advanced use cases in a community of people with talent far beyond what we could hire independently allows us to innovate at a level we could not reach on our own. Our engineers enjoy returning code to the community and participating in talks, blogs and meetings, its a great way for us to allow our team to express themselves and share the pride they have in their work.”</p>
<p>It also wanted to use a container-focused platform. Pearson has 400 development groups and diverse brands with varying business and technical needs. With containers, each brand could experiment with building new types of content using their preferred technologies, and then deliver it using containers. Pearson chose Kubernetes because it believes that is the best technology for managing containers, has the widest community support and offers the most flexible and powerful tools.“</p>
<p>Kubernetes is at the core of the platform weve built for developers. After we get our big spike in back-to-school in traffic, much of Pearsons traffic will interact with Kubernetes. It is proving to be as effective as we had hoped,” Jackson says.</p>
</div>
</main>
</section>
<section class="details">
<main>
<div class="content">
<h4>Encouraging experimentation, saving engineers time</h4>
<p>With the new platform, Pearson will increase stability and performance, and to bring products to market more quickly. The company says its engineers will also get a productivity boost because they wont spend time managing infrastructure. Jackson estimates 15 to 20 percent in productivity savings.</p>
<p>Beyond that, Pearson says the platform will encourage innovation because of the ease with which new applications can be developed, and because applications will be deployed far more quickly than in the past. It expects that will help the company meet its goal of reaching 200 million learners within the next 10 years.</p>
<p>“Were already seeing tremendous benefits with Kubernetes — improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online,” says Jackson.</p>
</div>
</main>
</section>
{% include footer.html %}
{% include case-study-styles.html %}
</body>
</html>
+103
View File
@@ -0,0 +1,103 @@
---
title: Wikimedia Case Study
---
<!Doctype html>
<html id="caseStudies" class="gridPage">
{% include head-header.html %}
<section id="hero" class="light-text">
<h1> Wikimedia Case Study</h1>
</section>
<section id="mainContent">
<main>
<div class="content">
<h3 id="caseStudyTitle">Using Kubernetes to Build Tools to Improve the World's Wikis</h3>
<p>
The non-profit Wikimedia Foundation operates some of the largest collaboratively edited reference projects in the world, including Wikipedia. To help users maintain and use wikis, it runs Wikimedia Tool Labs, a hosting environment for community developers working on tools and bots to help editors and other volunteers do their work, including reducing vandalism. The community around Wikimedia Tool Labs began forming nearly 10 years ago.
</p>
<div class="feature">
<img src="/images/case_studies/wikimedia.png" alt="Wikimedia">
<p class="quote">
“Wikimedia Tool Labs is vital for making sure wikis all around the world work as well as they possibly can. Because its grown organically for almost 10 years, it has become an extremely challenging environment and difficult to maintain. Its like a big ball of mud — you really cant see through it. With Kubernetes, were simplifying the environment and making it easier for developers to build the tools that make wikis run better.”
</p>
<p class="attrib">— Yuvi Panda, operations engineer at Wikimedia Foundation and Wikimedia Tool Labs</p>
</div>
</div>
</main>
</section>
<section class="bullets">
<main>
<div class="content">
<div class="bullet">
<h4>Challenges:</h4>
<ul>
<li>Simplify a complex, difficult-to-manage infrastructure</li>
<li>Allow developers to continue writing tools and bots using existing techniques</li>
</ul>
</div>
<div class="bullet">
<h4>Why Kubernetes:</h4>
<ul>
<li>Wikimedia Tool Labs chose Kubernetes because it can mimic existing workflows, while reducing complexity</li>
</ul>
</div>
<div class="bullet">
<h4>Approach:</h4>
<ul>
<li>Migrate old systems and a complex infrastructure to Kubernetes</li>
</ul>
</div>
<div class="bullet">
<h4>Results:</h4>
<ul>
<li>20 percent of web tools that account for more than 40 percent of web traffic now run on Kubernetes</li>
<li>A 25-node cluster that keeps up with each new Kubernetes release</li>
<li>Thousands of lines of old code have been deleted, thanks to Kubernetes</li>
</ul>
</div>
</div>
</main>
</section>
<section class="details">
<main>
<div class="content">
<h4>Using Kubernetes to provide tools for maintaining wikis</h4>
<p>
Wikimedia Tool Labs is run by a staff of four-and-a-half paid employees and two volunteers. The infrastructure didn't make it easy or intuitive for developers to build bots and other tools to make wikis work more easily. Yuvi says, “Its incredibly chaotic. We have lots of Perl and Bash duct tape on top of it. Everything is super fragile.”
</p>
<p>
To solve the problem, Wikimedia Tool Labs migrated parts of its infrastructure to Kubernetes, in preparation for eventually moving its entire system. Yuvi said Kubernetes greatly simplifies maintenance. The goal is to allow developers creating bots and other tools to use whatever development methods they want, but make it easier for the Wikimedia Tool Labs to maintain the required infrastructure for hosting and sharing them.
</p>
<p>
“With Kubernetes, Ive been able to remove a lot of our custom-made code, which makes everything easier to maintain. Our users code also runs in a more stable way than previously,” says Yuvi.
</p>
</div>
</main>
</section>
<section class="details">
<main>
<div class="content">
<h4>Simplifying infrastructure and keeping wikis running better</h4>
<p>
Wikimedia Tool Labs has seen great success with the initial Kubernetes deployment. Old code is being simplified and eliminated, contributing developers dont have to change the way they write their tools and bots, and those tools and bots run in a more stable fashion than they have in the past. The paid staff and volunteers are able to better keep up with fixing issues.
</p>
<p>
In the future, with a more complete migration to Kubernetes, Wikimedia Tool Labs expects to make it even easier to host and maintain the bots and tools that help run wikis across the world. The tool labs already host approximately 1,300 tools and bots from 800 volunteers, with many more being submitted every day. Twenty percent of the tool labs web tools that account for more than 60 percent of web traffic now run on Kubernetes. The tool labs has a 25-node cluster that keeps up with each new Kubernetes release. Many existing web tools are migrating to Kubernetes.
</p>
<p>
“Our goal is to make sure that people all over the world can share knowledge as easily as possible. Kubernetes helps with that, by making it easier for wikis everywhere to have the tools they need to thrive,” says Yuvi.
</p>
</div>
</main>
</section>
{% include footer.html %}
{% include case-study-styles.html %}
</body>
</html>
+68
View File
@@ -0,0 +1,68 @@
---
title: Community
---
<!Doctype html>
<html id="community">
{% include head-header.html %}
<section id="hero" class="light-text">
<h1>Community</h1>
</section>
<section id="mainContent">
<main>
<div class="content">
<h3>Ensuring Kubernetes works well everywhere and for everyone.</h3>
<p>Connect with the Kubernetes community on our <a href="http://slack.k8s.io/">Slack channel</a> or join the
<a href="https://groups.google.com/forum/#!forum/kubernetes-dev">Kubernetes-dev Google group</a>. A weekly
community meeting takes place via video conference to discuss the state of affairs,
<a href="https://groups.google.com/forum/#!forum/kubernetes-community-video-chat">get a calendar invite</a>
to participate.</p>
</div>
<div class="content">
<h3>SIGs</h3>
<p>Have a special interest in how Kubernetes works with another technology? See our ever growing
<a href="https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs)">lists of SIGs</a>,
from AWS and Openstack to Big Data and Scalability, theres a place for you to contribute and instructions
for forming a new SIG if your special interest isnt covered (yet).</p>
</div>
<div class="content">
<h3>Events</h3>
<div id="calendarWrapper">
<iframe src="https://calendar.google.com/calendar/embed?src=nt2tcnbtbied3l6gi2h29slvc0%40group.calendar.google.com&ctz=America/Los_Angeles"
frameborder="0" scrolling="no"></iframe>
</div>
</div>
</main>
</section>
<section id="talkToUs">
<main>
<h3>Talk to Us!</h3>
<h4>We would love to hear from you, how you are using Kubernetes,<br> and what we can do to make it better.</h4>
<div id="bigSocial">
<div>
<a href="https://twitter.com/kubernetesio">@kubernetesio</a>
<p>Get the latest news and updates.</p>
</div>
<div>
<a href="https://github.com/kubernetes/kubernetes">Github Project</a>
<p>Check out the project and consider contributing.</p>
</div>
<div>
<a href="http://slack.k8s.io/">#kubernetes-users</a>
<p>Our Slack channel is the best way to contact our engineers and share your ideas with them.</p>
</div>
<div>
<a href="http://stackoverflow.com/questions/tagged/kubernetes">Stack Overflow</a>
<p>Our user forum is a great place to go for community support.</p>
</div>
</div>
</main>
</section>
{% include footer.html %}
</body>
</html>
-158
View File
@@ -1,158 +0,0 @@
baseURL = "https://kubernetes.io"
title = "Kubernetes"
defaultContentLanguage = "en"
defaultContentLanguageInSubdir = false
enableRobotsTXT = true
disableKinds = ["taxonomy", "taxonomyTerm"]
ignoreFiles = [ "^OWNERS$", "README[-]+[a-z]*\\.md", "^node_modules$", "content/en/docs/doc-contributor-tools" ]
contentDir = "content/en"
timeout = 3000
# Highlighting config.
pygmentsCodeFences = true
pygmentsUseClasses = false
# See https://help.farbox.com/pygments.html
pygmentsStyle = "emacs"
# Enable Git variables like commit, lastmod
enableGitInfo = true
# Norwegian ("no") is sometimes but not currently used for testing.
disableLanguages = ["no"]
[blackfriday]
hrefTargetBlank = true
fractions = false
[frontmatter]
date = ["date", ":filename", "publishDate", "lastmod"]
[permalinks]
blog = "/:section/:year/:month/:day/:slug/"
# Be explicit about the output formats. We (currently) only want an RSS feed for the home page.
[outputs]
home = [ "HTML", "RSS", "HEADERS" ]
page = [ "HTML"]
section = [ "HTML"]
# Add a "text/netlify" media type for auto-generating the _headers file
[mediaTypes]
[mediaTypes."text/netlify"]
delimiter = ""
[outputFormats]
[outputFormats.RSS]
baseName = "feed"
# _headers file output (uses the template at layouts/index.headers)
[outputFormats.HEADERS]
mediatype = "text/netlify"
baseName = "_headers"
isPlainText = true
notAlternative = true
[params]
time_format_blog = "Monday, January 02, 2006"
description = "Production-Grade Container Orchestration"
showedit = true
latest = "v1.15"
fullversion = "v1.11.10"
version = "v1.11"
githubbranch = "v1.11.10"
docsbranch = "release-1.11"
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"
[[params.versions]]
fullversion = "v1.15.0"
version = "v1.15"
githubbranch = "v1.15.0"
docsbranch = "release-1.15"
url = "https://kubernetes.io"
[params.pushAssets]
css = [
"callouts",
"styles",
"custom-jekyll/tags"
]
js = [
"custom-jekyll/tags",
"script"
]
[[params.versions]]
fullversion = "v1.14.3"
version = "v1.14"
githubbranch = "v1.14.3"
docsbranch = "release-1.14"
url = "https://v1-14.docs.kubernetes.io"
[[params.versions]]
fullversion = "v1.13.7"
version = "v1.13"
githubbranch = "v1.13.7"
docsbranch = "release-1.13"
url = "https://v1-13.docs.kubernetes.io"
[[params.versions]]
fullversion = "v1.12.9"
version = "v1.12"
githubbranch = "v1.12.9"
docsbranch = "release-1.12"
url = "https://v1-12.docs.kubernetes.io"
[[params.versions]]
fullversion = "v1.11.10"
version = "v1.11"
githubbranch = "v1.11.10"
docsbranch = "release-1.11"
url = "https://v1-11.docs.kubernetes.io"
# Language definitions.
[languages]
[languages.en]
title = "Kubernetes"
description = "Production-Grade Container Orchestration"
languageName ="English"
# Weight used for sorting.
weight = 1
[languages.zh]
title = "Kubernetes"
description = "Production-Grade Container Orchestration"
languageName = "中文 Chinese"
weight = 2
contentDir = "content/zh"
[languages.ko]
title = "Kubernetes"
description = "Production-Grade Container Orchestration"
languageName = "한국어 Korean"
weight = 3
contentDir = "content/ko"
[languages.no]
title = "Kubernetes"
description = "Production-Grade Container Orchestration"
languageName ="Norsk"
weight = 4
contentDir = "content/no"
[languages.no.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"]
View File
-153
View File
@@ -1,153 +0,0 @@
---
title: "生产级别的容器编排系统"
abstract: "自动化的容器部署、扩展和管理"
cid: "home"
---
<section id="oceanNodes">
<main>
<div class="image-wrapper"><img src="/images/flower.png"></div>
<div class="content">
<h3><a href="/docs/concepts/overview/what-is-kubernetes/">Kubernetes</a> 是用于自动部署,扩展和管理容器化应用程序的开源系统。</h3>
<p>它将组成应用程序的容器组合成逻辑单元,以便于管理和服务发现,Kubernetes 构建在 <a href="http://queue.acm.org/detail.cfm?id=2898444"> Google 15 年生产环境经验</a>基础之上,并结合来自社区的最佳创意和实践。</p>
</div>
</main>
<main>
<div class="image-wrapper"><img src="/images/scalable.png"></div>
<div class="content">
<h4>星际尺度</h4>
<p>根据同样的原则设计,允许 Google 每周运行数十亿个容器,Kubernetes 可以在不增加您的 ops 团队的情况下进行弹性扩展。</p>
</div>
</main>
<main>
<div class="image-wrapper"><img src="/images/blocks.png"></div>
<div class="content">
<h4>永不过时</h4>
<p>无论您应用运行在本地还是运行于全球任何地域,Kubernetes 的灵活性都可以随着您的需求复杂度不断增加,还可以持续、轻松地对外提供服务。</p>
</div>
</main>
<main>
<div class="image-wrapper"><img src="/images/suitcase.png"></div>
<div class="content">
<h4>随处运行</h4>
<p>Kubernetes 是开源的,可以让您自由地部署在企业内部,私有云、混合云或公有云基础架构,使您轻松将应用迁移至任何位置。</p>
</div>
</main>
</section>
<section id="video">
<div class="light-text">
<h2>Kubernetes: 最后&hellip; 它是真正的云平台</h2>
<p>Box 的联合创始人和服务架构师 Sam Ghods 发表了热情洋溢的演讲,随着使用 Kubernetes,我们首次有一个通用接口,可以建立真正的部署工具。</p>
<button id="desktopShowVideoButton" onclick="kub.showVideo()">观看视频</button>
</div>
<button id="mobileShowVideoButton" onclick="kub.showVideo()"></button>
</section>
<section id="features">
<main>
<h3 class="center">Kubernetes 特性</h3>
<div class="feature-box">
<div>
<h4><a href="/docs/concepts/configuration/manage-compute-resources-container/">自动包装</a></h4>
<p>根据资源需求和其他约束自动放置容器,同时不会牺牲可用性,混合关键和最大努力的工作负载,以提高资源利用率并节省更多资源。</p>
</div>
<div>
<h4><a href="/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller">自我修复</a></h4>
<p>重新启动失败的容器,在节点不可用时,替换和重新编排节点上的容器,终止不对用户定义的健康检查做出响应的容器,并且不会在客户端准备投放之前将其通告给客户端。</p>
</div>
</div>
<div class="feature-box">
<div>
<h4><a href="/docs/tasks/run-application/horizontal-pod-autoscale/">横向缩放</a></h4>
<p>使用简单的命令或 UI,或者根据 CPU 的使用情况自动调整应用程序副本数。</p>
</div>
<div>
<h4><a href="/docs/concepts/services-networking/service/">服务发现和负载均衡</a></h4>
<p>不需要修改您的应用程序来使用不熟悉的服务发现机制,Kubernetes 为容器提供了自己的 IP 地址和一组容器的单个 DNS 名称,并可以在它们之间进行负载均衡。</p>
</div>
</div>
<div class="feature-box">
<div>
<h4><a href="/docs/concepts/workloads/controllers/deployment/#what-is-a-deployment">自动部署和回滚</a></h4>
<p>Kubernetes 逐渐部署对应用程序或其配置的更改,同时监视应用程序运行状况,以确保它不会同时终止所有实例。 如果出现问题,Kubernetes会为您恢复更改,利用日益增长的部署解决方案的生态系统。</p>
</div>
<div>
<h4><a href="/docs/concepts/configuration/secret/">密钥</a><a href="/docs/tasks/configure-pod-container/configure-pod-configmap/">配置</a> 管理</h4>
<p>部署和更新密钥和应用程序配置,不会重新编译您的镜像,不会在堆栈配置中暴露密钥(secrets)。</p>
</div>
</div>
<div class="feature-box">
<div>
<h4><a href="/docs/concepts/storage/persistent-volumes/">存储编排</a></h4>
<p>自动安装您所选择的存储系统,无论是本地存储,如公有云提供商 <a href="https://cloud.google.com/storage/">GCP</a><a href="https://aws.amazon.com/products/storage/">AWS</a>, 还是网络存储系统 NFS, iSCSI,
Gluster, Ceph, Cinder, 或 Flocker。</p>
</div>
<div>
<h4><a href="/docs/concepts/workloads/controllers/jobs-run-to-completion/">批处理</a></h4>
<p>除了服务之外,Kubernetes还可以管理您的批处理和 CI 工作负载,如果需要,替换出现故障的容器。</p>
</div>
</div>
</main>
</section>
<section id="talkToUs">
<main>
<h3>实例探究</h3>
<div id="caseStudiesWrapper">
<div>
<p>使用Kubernetes来重塑世界上最大的教育公司</p>
<a href="/case-studies/pearson/">阅读更多</a>
</div>
<div>
<p>Kubernetes at Box: 微服务的最大优势</p>
<a href="https://blog.box.com/blog/kubernetes-box-microservices-maximum-velocity/">阅读更多</a>
</div>
<div>
<p>在 eBay 内部转移到 OpenStack 上的 Kubernetes 和容器</p>
<a href="https://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/">阅读更多</a>
</div>
<div>
<p>将本地的集群迁移至 Kubernetes</p>
<a href="https://www.youtube.com/watch?v=6XGUTu3WhBw">观看视频</a>
</div>
</div>
<h5 style="text-align: center"><a href="/case-studies/" style="color: #3371E3; font-weight: 400">探究所有的案例</a></h5>
</main>
</section>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/of45hYbkIZs?autoplay=1" frameborder="0" allowfullscreen></iframe>
<button id="closeButton"></button>
</div>
View File
-4
View File
@@ -1,4 +0,0 @@
---
title: Home
weight: 5
---
-135
View File
@@ -1,135 +0,0 @@
---
approvers:
- bgrant0607
- erictune
- lavalamp
title: Kubernetes API访问控制
---
用户通过 `kubectl`、客户端库或者通过发送REST请求[访问API](/docs/user-guide/accessing-the-cluster)。 用户(自然人)和[Kubernetes服务账户](/docs/tasks/configure-pod-container/configure-service-account/) 都可以被授权进行API访问。
请求到达API服务器后会经过几个阶段,具体说明如图:
![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg)
## 传输层安全
在典型的Kubernetes集群中,API通过443端口提供服务。
API服务器会提供一份证书。 该证书一般是自签名的, 所以用户机器上的 `$USER/.kube/config` 目录通常
包含该API服务器证书的根证书,用来代替系统默认根证书。 当用户使用 `kube-up.sh` 创建集群时,该证书通常会被自动写入用户的`$USER/.kube/config`。 如果集群中存在多个用户,则创建者需要与其他用户共享证书。
## 认证
一旦 TLS 连接建立,HTTP请求就进入到了认证的步骤。即图中的步骤 **1**
集群创建脚本或集群管理员会为API服务器配置一个或多个认证模块。
更具体的认证相关的描述详见 [这里](/docs/admin/authentication/)。
认证步骤的输入是整个HTTP请求,但这里通常只是检查请求头和/或客户端证书。
认证模块支持客户端证书,密码和Plain Tokens
Bootstrap Tokens,以及JWT Tokens (用于服务账户)。
(管理员)可以同时设置多种认证模块,在设置了多个认证模块的情况下,每个模块会依次尝试认证,
直到其中一个认证成功。
在 GCE 平台中,客户端证书,密码和Plain TokensBootstrap Tokens,以及JWT Tokens同时被启用。
如果请求认证失败,则请求被拒绝,返回401状态码。
如果认证成功,则被认证为具体的 `username`,该用户名可供随后的步骤中使用。一些认证模块还提供了用户的组成员关系,另一些则没有。
尽管Kubernetes使用 "用户名" 来进行访问控制和请求记录,但它实际上并没有 `user` 对象,也不存储用户名称或其他相关信息。
## 授权
当请求被认证为来自某个特定的用户后,该请求需要被授权。 即图中的步骤 **2** 。
请求须包含请求者的用户名,请求动作,以及该动作影响的对象。 如果存在相应策略,声明该用户具有进行相应操作的权限,则该请求会被授权。
例如,如果Bob有如下策略,那么他只能够读取`projectCaribou`命名空间下的pod资源:
```json
{
"apiVersion": "abac.authorization.kubernetes.io/v1beta1",
"kind": "Policy",
"spec": {
"user": "bob",
"namespace": "projectCaribou",
"resource": "pods",
"readonly": true
}
}
```
如果Bob发起以下请求,那么请求能够通过授权,因为Bob被允许访问 `projectCaribou` 命名空间下的对象:
```json
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"spec": {
"resourceAttributes": {
"namespace": "projectCaribou",
"verb": "get",
"group": "unicorn.example.org",
"resource": "pods"
}
}
}
```
如果Bob对 `projectCaribou` 命名空间下的对象发起一个写(`create` 或者 `update`)请求,那么它的授权会被拒绝。 如果Bob请求读取(`get`) 其他命名空间,例如 `projectFish`下的对象,其授权也会被拒绝。
Kubernetes的授权要求使用通用的REST属性与现有的组织或云服务提供商的访问控制系统进行交互。 采用REST格式是必要的,因为除Kubernetes外,这些访问控制系统还可能与其他的API进行交互。
Kubernetes 支持多种授权模块,例如ABAC模式,RBAC模式和 Webhook模式。 管理员创建集群时,会配置API服务器应用的授权模块。 如果多种授权模式同时被启用,Kubernetes将检查所有模块,如果其中一种通过授权,则请求授权通过。 如果所有的模块全部拒绝,则请求被拒绝(HTTP状态码403)。
要了解更多的Kubernetes授权相关信息,包括使用授权模块创建策略的具体说明等,可参考[授权概述](/docs/admin/authorization)。
## 准入控制
准入控制模块是能够修改或拒绝请求的软件模块。
作为授权模块的补充,准入控制模块会访问被创建或更新的对象的内容。
它们作用于对象的创建,删除,更新和连接 (proxy)阶段,但不包括对象的读取。
可以同时配置多个准入控制器,它们会按顺序依次被调用。
即图中的步骤 **3** 。
与认证和授权模块不同的是,如果任一个准入控制器拒绝请求,那么整个请求会立即被拒绝。
除了拒绝请求外,准入控制器还可以为对象设置复杂的默认值。
可用的准入控制模块描述 [如下](/docs/admin/admission-controllers/)。
一旦请求通过所有准入控制器,将使用对应API对象的验证流程对其进行验证,然后写入对象存储 (如步骤 **4**)。
## API的端口和IP
上述讨论适用于发送请求到API服务器的安全端口(典型情况)。
实际上API服务器可以通过两个端口提供服务:
默认情况下,API服务器在2个端口上提供HTTP服务:
1. `Localhost Port`:
- 用于测试和启动,以及管理节点的其他组件
(scheduler, controller-manager)与API的交互
- 没有TLS
- 默认值为8080,可以通过 `--insecure-port` 标记来修改。
- 默认的IP地址为localhost, 可以通过 `--insecure-bind-address`标记来修改。
- 请求会 **绕过** 认证和鉴权模块。
- 请求会被准入控制模块处理。
- 其访问需要主机访问的权限。
2. `Secure Port`:
- 尽可能使用该端口访问
- 应用 TLS。 可以通过 `--tls-cert-file` 设置证书, 通过 `--tls-private-key-file` 设置私钥。
- 默认值为6443,可以通过 `--secure-port` 标记来修改。
- 默认IP是首个非本地的网络接口地址,可以通过 `--bind-address` 标记来修改。
- 请求会经过认证和鉴权模块处理。
- 请求会被准入控制模块处理。
- 要求认证和授权模块正常运行。
通过 `kube-up.sh`创建集群时, 对 Google Compute Engine (GCE)
和一些其他的云供应商来说, API通过443端口提供服务。 对
GCE而言,项目上配置了防火墙规则,允许外部的HTTPS请求访问API,其他(厂商的)集群设置方法各不相同。
@@ -1,156 +0,0 @@
---
approvers:
- erictune
- lavalamp
- deads2k
- liggitt
title: 概述
content_template: templates/concept
---
{{% capture overview %}}
学习有关 Kubernetes 授权的更多信息,包括有关使用支持的授权模块创建策略的详细信息。
{{% /capture %}}
{{% capture body %}}
在 Kubernetes 里,您必须经过身份验证(登录),才能授权您的请求(授予访问权限).。有关认证的信息,请参阅[访问控制概述](/docs/admin/access-the-api/)。
Kubernetes 提供通用的 REST API 请求。这意味着 Kubernetes 授权可以与现有的组织或云提供商的访问控制系统一起使用,该系统可以处理除 Kubernetes API 之外的其他 API。
## 确定请求是允许还是被拒绝
Kubernetes 使用 API 服务器授权 API 请求。它根据所有策略评估所有请求属性,并允许或拒绝请求。某些策略必须允许 API 请求的所有部分继续进行,这意味着默认情况下是拒绝权限。
(虽然 Kubernetes 使用 API ​​服务器,访问控制和依赖特定类型对象的特定领域策略由 Admission 控制器处理。)
当配置多个授权模块时,按顺序检查每个模块,如果有任何模块授权请求,则可以继续执行该请求。如果所有模块拒绝请求,则拒绝该请求(HTTP状态代码403)。
## 查看您的请求属性
Kubernetes 仅查看以下API请求属性:
* **user** - 验证期间提供的 `user` 字符串
* **group** - 认证用户所属的组名列表
* **“extra"** - 由认证层提供的任意字符串键到字符串值的映射
* **API** - 指示请求是否用于API资源
* **Request path** - 诸如`/api``/healthz`的其他非资源端点的路径(请参阅[kubectl](#kubectl)).
* **API request verb** - API 动词 `get``list``create``update``patch``watch``proxy``redirect``delete``deletecollection`用于资源请求。要确定资源 API 端点的请求动词,请参阅**确定下面的请求动词**.
* **HTTP request verb** - HTTP动词`get``post``put``delete`用于非资源请求
* **Resource** - 正在访问的资源的ID或名称(仅适用于资源请求)
--* 对于使用`get`, `update`, `patch`, 和 `delete`动词的资源请求,您必须提供资源名称。
* **Subresource** - 正在访问的子资源(仅用于资源请求)
* **Namespace** - 正在被访问的对象的命名空间(仅针对命名空间的资源请求)
* **API group** - 正在访问的API组(仅用于资源请求). 一个空字符串指定[核心 API 组](/docs/api/).
## 确定请求动词
要确定资源 API 端点的请求动词,请查看所使用的HTTP动词以及请求是否对单个资源或资源集合进行操作:
HTTP动词| 请求动词
---------- | ---------------
POST | 创建
GETHEAD | 获取(个人资源),列表(集合)
PUT | 更新
PATCH | 补丁
DELETE| 删除(个人资源),删除(收藏)
Kubernetes 有时会使用专门的动词检查授权以获得额外的权限。例如:
* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)在`extensions` API组中的`podsecuritypolicies`资源上检查`use`动词的授权。
* [RBAC](/docs/admin/authorization/rbac/#privilege-escalation-prevention-and-bootstrapping) 在`rbac.authorization.k8s.io` API组中的`roles``clusterroles`资源上检查`bind`动词的授权。
* [认证](/docs/admin/authentication/) 在核心API组中的`users``groups``serviceaccounts`上的`impersonate`动词的授权以及`authentication.k8s.io` API组中的`userextras`进行层次检查。
## 授权模块
* **ABAC模式** - 基于属性的访问控制(ABAC)定义了访问控制范例,通过使用将属性组合在一起的策略来授予用户访问权限。策略可以使用任何类型的属性(用户属性,资源属性,对象,环境属性等)。要了解有关使用ABAC模式的更多信息,请参阅[ABAC模式](/docs/admin/authorization/abac/)
* **RBAC模式** - 基于角色的访问控制(RBAC)是一种根据企业内个人用户的角色来调整对计算机或网络资源的访问的方法。在这种情况下,访问是单个用户执行特定任务(例如查看,创建或修改文件)的能力。要了解有关使用RBAC模式的更多信息,请参阅[RBAC模式](/docs/admin/authorization/rbac/)
*当指定 "RBAC"(基于角色的访问控制)使用 "rbac.authorization.k8s.io" API组来驱动授权决定时,允许管理员通过Kubernetes API动态配置权限策略.
.. *截至1.6 RBAC模式是测试版.
.. *要启用RBAC,请使用 `--authorization-mode=RBAC` 启动 apiserver.
* **Webhook模式** - WebHook 是HTTP回调:发生事件时发生的HTTP POST; 通过HTTP POST简单的事件通知. 实施 WebHooks 的 Web 应用程序将在某些事情发生时向URL发送消息. 要了解有关使用Webhook模式的更多信息,请参阅[Webhook模式](/docs/admin/authorization/webhook/)
* **自定义模块** - 您可以创建使用Kubernetes的自定义模块. 要了解更多信息,请参阅下面的**自定义模块**。
### 自定义模块
可以相当容易地开发其他实现,APIserver 调用 Authorizer 接口:
```go
type Authorizer interface {
Authorize(a Attributes) error
}
```
以确定是否允许每个API操作.
授权插件是实现此接口的模块.授权插件代码位于 `pkg/auth/authorizer/$MODULENAME` 中。
授权模块可以完全实现,也可以拨出远程授权服务。 授权模块可以实现自己的缓存,以减少具有相同或相似参数的重复授权调用的成本。 开发人员应该考虑缓存和撤销权限之间的交互。
#### 检查API访问
Kubernetes 将 `subjectaccessreviews.v1.authorization.k8s.io` 资源公开为允许外部访问API授权者决策的普通资源。 无论您选择使用哪个授权器,您都可以使用`SubjectAccessReview`发出一个`POST`,就像webhook授权器的`apis/authorization.k8s.io/v1/subjectaccessreviews` 端点一样,并回复一个响应。 例如:
```bash
kubectl create --v=8 -f - << __EOF__
{
"apiVersion": "authorization.k8s.io/v1",
"kind": "SubjectAccessReview",
"spec": {
"resourceAttributes": {
"namespace": "kittensandponies",
"verb": "get",
"group": "unicorn.example.org",
"resource": "pods"
},
"user": "jane",
"group": [
"group1",
"group2"
],
"extra": {
"scopes": [
"openid",
"profile"
]
}
}
}
__EOF__
--- snip lots of output ---
I0913 08:12:31.362873 27425 request.go:908] Response Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1","metadata":{"creationTimestamp":null},"spec":{"resourceAttributes":{"namespace":"kittensandponies","verb":"GET","group":"unicorn.example.org","resource":"pods"},"user":"jane","group":["group1","group2"],"extra":{"scopes":["openid","profile"]}},"status":{"allowed":true}}
subjectaccessreview "" created
```
这对于调试访问问题非常有用,因为您可以使用此资源来确定授权者授予哪些访问权限。
## 为您的授权模块使用标志
您的策略中必须包含一个标志,以指出您的策略包含哪个授权模块:
可以使用以下标志:
- `--authorization-mode=ABAC` 基于属性的访问控制(ABAC)模式允许您使用本地文件配置策略。
- `--authorization-mode=RBAC` 基于角色的访问控制(RBAC)模式允许您使用Kubernetes API创建和存储策略.
- `--authorization-mode=Webhook` WebHook是一种HTTP回调模式,允许您使用远程REST管理授权。
- `--authorization-mode=AlwaysDeny` 此标志阻止所有请求. 仅使用此标志进行测试。
- `--authorization-mode=AlwaysAllow` 此标志允许所有请求. 只有在您不需要API请求授权的情况下才能使用此标志。
您可以选择多个授权模块. 如果其中一种模式为 `AlwaysAllow`,则覆盖其他模式,并允许所有API请求。
## 版本控制
对于版本 1.2,配置了 kube-up.sh 创建的集群,以便任何请求都不需要授权。
从版本 1.3 开始,配置由 kube-up.sh 创建的集群,使得 ABAC 授权模块处于启用状态。但是,其输入文件最初设置为允许所有用户执行所有操作,集群管理员需要编辑该文件,或者配置不同的授权器来限制用户可以执行的操作。
{{% /capture %}}
{{% capture whatsnext %}}
* 要学习有关身份验证的更多信息,请参阅**身份验证**[控制访问 Kubernetes API](docs/admin/access-the-api/)。
* 要了解有关入学管理的更多信息,请参阅[使用 Admission 控制器](docs/admin/admission-controllers/)。
*
{{% /capture %}}
-142
View File
@@ -1,142 +0,0 @@
---
approvers:
- erictune
- lavalamp
- deads2k
- liggitt
title: ABAC 模式
content_template: templates/concept
---
{{% capture overview %}}
基于属性的访问控制(Attribute-based access control - ABAC)定义了访问控制范例,其中通过使用将属性组合在一起的策略来向用户授予访问权限。
{{% /capture %}}
{{% capture body %}}
## 策略文件格式
基于 `ABAC` 模式,可以这样指定策略文件 `--authorization-policy-file=SOME_FILENAME`
此文件是 JSON 格式[每行都是一个JSON对象](http://jsonlines.org/),不应存在封闭的列表或映射,每行只有一个映射。
每一行都是一个 "策略对象",策略对象是具有以下映射的属性:
- 版本控制属性:
- `apiVersion`,字符串类型: 有效值为"abac.authorization.kubernetes.io/v1beta1",允许版本控制和转换策略格式。
- `kind`,字符串类型: 有效值为 "Policy",允许版本控制和转换策略格式。
- `spec` 配置为具有以下映射的属性:
- 匹配属性:
- `user`,字符串类型; 来自 `--token-auth-file` 的用户字符串,如果你指定`user`,它必须与验证用户的用户名匹配。
- `group`,字符串类型; 如果指定`group`,它必须与经过身份验证的用户的一个组匹配,`system:authenticated`匹配所有经过身份验证的请求。`system:unauthenticated`匹配所有未经过身份验证的请求。
- 资源匹配属性:
- `apiGroup`,字符串类型; 一个 API 组。
- 例: `extensions`
- 通配符: `*`匹配所有 API 组。
- `namespace`,字符串类型; 一个命名空间。
- 例如: `kube-system`
- 通配符: `*` 匹配所有资源请求。
- `resource`,字符串类型; 资源类型。
- 例:`pods`
- 通配符: `*`匹配所有资源请求。
- 非资源匹配属性:
- `nonResourcePath`,字符串类型; 非资源请求路径。
- 例如:`/version``/apis`
- 通配符:
- `*` 匹配所有非资源请求。
- `/foo/*` 匹配`/foo/`的所有子路径。
- `readonly`,键入 boolean,如果为 true,则表示该策略仅适用于 getlist 和 watch 操作。
**注意:** 未设置的属性与类型设置为零值的属性相同(例如空字符串,0、false),然而未知的应该可读性优先。
在将来,策略可能以 JSON 格式表示,并通过 REST 界面进行管理。
## 授权算法
请求具有与策略对象的属性对应的属性。
当接收到请求时,确定属性。 未知属性设置为其类型的零值(例如: 空字符串,0,false)。
设置为`“*"`的属性将匹配相应属性的任何值。
检查属性的元组,以匹配策略文件中的每个策略。 如果至少有一行匹配请求属性,则请求被授权(但可能会在稍后验证失败)。
要允许任何经过身份验证的用户执行某些操作,请将策略组属性设置为 `"system:authenticated“`
要允许任何未经身份验证的用户执行某些操作,请将策略组属性设置为`"system:authentication“`
要允许用户执行任何操作,请使用 apiGroup,命名空间,
资源和 nonResourcePath 属性设置为 `“*"`的策略.
要允许用户执行任何操作,请使用设置为`“*”` 的 apiGroupnamespaceresource 和 nonResourcePath 属性编写策略。
## Kubectl
Kubectl 使用 api-server 的 `/api``/apis` 端点进行协商客户端/服务器版本。 通过创建/更新来验证发送到API的对象操作,kubectl 查询某些 swagger 资源。 对于API版本"v1", 那就是`/swaggerapi/api/v1` `/swaggerapi/ experimental/v1`
当使用 ABAC 授权时,这些特殊资源必须明确通过策略中的 `nonResourcePath` 属性暴露出来(参见下面的[例子](#examples)):
* `/api``/api/*``/apis``/apis/*` 用于 API 版本协商.
* `/version` 通过 `kubectl version` 检索服务器版本.
* `/swaggerapi/*` 用于创建/更新操作.
要检查涉及到特定kubectl操作的HTTP调用,您可以调整详细程度:
kubectl --v=8 version
## 例子
1. Alice 可以对所有资源做任何事情:
```json
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}
```
2. Kubelet 可以读取任何pod:
```json
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}
```
3. Kubelet 可以读写事件:
```json
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}}
```
4. Bob 可以在命名空间“projectCaribou"中读取 pod:
```json
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}
```
5. 任何人都可以对所有非资源路径进行只读请求:
```json
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:authenticated", "readonly": true, "nonResourcePath": "*"}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
```
[完整文件示例](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
## 服务帐户的快速说明
服务帐户自动生成用户。 用户名是根据命名约定生成的:
```shell
system:serviceaccount:<namespace>:<serviceaccountname>
```
创建新的命名空间也会导致创建一个新的服务帐户:
```shell
system:serviceaccount:<namespace>:default
```
例如,如果要将 API 的 kube-system 完整权限中的默认服务帐户授予,则可以将此行添加到策略文件中:
```json
{"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:kube-system:default","namespace":"*","resource":"*","apiGroup":"*"}}
```
需要重新启动 apiserver 以获取新的策略行.
{{% /capture %}}
@@ -1,143 +0,0 @@
---
approvers:
- erictune
- lavalamp
- deads2k
- liggitt
title: Webhook Mode
content_template: templates/concept
---
{{% capture overview %}}
WebHook 是一种 HTTP 回调:某些条件下触发的 HTTP POST 请求;通过 HTTP POST 发送的简单事件通知。一个基于 web 应用实现的 WebHook 会在特定事件发生时把消息发送给特定的 URL 。
{{% /capture %}}
{{% capture body %}}
具体来说,当在判断用户权限时,`Webhook` 模式会使 Kubernetes 查询外部的 REST 服务。
## 配置文件格式
`Webhook` 模式需要一个 HTTP 配置文件,通过 `--authorization-webhook-config-file=SOME_FILENAME` 的参数声明。
配置文件的格式使用 [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)。
在文件中,"users" 代表着 API 服务器的 webhook,而 "cluster" 代表着远程服务。
使用 HTTPS 客户端认证的配置例子:
```yaml
# clusters 代表远程服务。
clusters:
- name: name-of-remote-authz-service
cluster:
certificate-authority: /path/to/ca.pem # 对远程服务进行身份认证的CA。
server: https://authz.example.com/authorize # 远程服务的查询 URL. 必须使用 'https'。
# users 代表 API 服务器的 webhook 配置.
users:
- name: name-of-api-server
user:
client-certificate: /path/to/cert.pem # webhook plugin 使用的 cert。
client-key: /path/to/key.pem # cert 所对应的 key。
# kubeconfig 文件必须有 context 。 需要提供一个给 API 服务器。
current-context: webhook
contexts:
- context:
cluster: name-of-remote-authz-service
user: name-of-api-server
name: webhook
```
## 请求载荷
在做认证决策时,API 服务器会 POST 一个 JSON 序列化的 api.authorization.v1beta1.SubjectAccessReview 对象来描述这个动作。这个对象包含了描述用户请求的字段,同时也包含了需要被访问资源或者请求特征的具体信息。
需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都服从 [版本兼容规则](/docs/api/) 。
实施人员应该了解 beta 对象的更宽松的兼容性承诺,同时确认请求的 "apiVersion" 字段以确保能被正确地反序列化。
此外,API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组(`--runtime-config=authorization.k8s.io/v1beta1=true`)。
一个请求内容的例子:
```json
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"spec": {
"resourceAttributes": {
"namespace": "kittensandponies",
"verb": "get",
"group": "unicorn.example.org",
"resource": "pods"
},
"user": "jane",
"group": [
"group1",
"group2"
]
}
}
```
远程服务被预期能填写请求和反馈的 SubjectAccessReviewStatus 字段,无论是允许访问还是拒绝访问。
反馈内容的 "spec" 字段是被忽略的,也是可以被省略的。当请求是被允许的时候,返回的响应如下例所示:
```json
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"status": {
"allowed": true
}
}
```
如拒绝,远程服务器会返回:
```json
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"status": {
"allowed": false,
"reason": "user does not have read access to the namespace"
}
}
```
对于非资源的路径访问是这么发送的:
```json
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"spec": {
"nonResourceAttributes": {
"path": "/debug",
"verb": "get"
},
"user": "jane",
"group": [
"group1",
"group2"
]
}
}
```
非资源类的路径包括:`/api`, `/apis`, `/metrics`, `/resetMetrics`,
`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, and
`/version`。 客户端需要访问 `/api`, `/api/*`, `/apis`, `/apis/*`, 和 `/version` 以便
能发现服务器上有什么资源和版本。对于其他非资源类的路径访问在没有 REST API 访问限制的情况下拒绝。
更多信息可以参考 uthorization.v1beta1 API 对象和
[webhook.go](https://git.k8s.io/kubernetes/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go).
{{% /capture %}}
-136
View File
@@ -1,136 +0,0 @@
---
approvers:
- jbeda
title: 使用启动引导令牌(Bootstrap Tokens)认证
---
{{< toc >}}
## 概述
启动引导令牌是一种简单的持有者令牌(Bearer Token),这种令牌是在新建集群或者在现有集群中添加新节点时使用的。
它被设计成能够支持 [`kubeadm`](/docs/admin/kubeadm/),但是也可以被用在其他的案例中以便用户在
不使用 `kubeadm` 的情况下启动集群。它也被设计成可以通过 RBAC 策略,结合 [Kubelet TLS
Bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) 系统进行工作。
启动引导令牌被定义成一个特定类型的 secrets(`bootstrap.kubernetes.io/token`),并存在于
`kube-system` 命名空间中。然后这些 secrets 会被 API 服务器上的启动引导的认证器读取。
控制器管理器中的控制器TokenCleaner能够删除过期的令牌。在节点发现的过程中Kubernetes会使用特殊的ConfigMap对象。
控制器管理器中的BootstrapSigner控制器也会使用启动引导令牌为这类对象生成签名信息。
目前,启动引导令牌处于 **alpha** 阶段,但是预期也不会有大的突破性变化。
## 令牌格式
启动引导令牌使用 `abcdef.0123456789abcdef` 的形式。
更加规范地说,它们必须符合正则表达式 `[a-z0-9]{6}\.[a-z0-9]{16}`
令牌的第一部分是 "Token ID" ,它是公共信息。用于引用某个令牌,并确保不会泄露认证所使用的秘密信息。
第二部分是 "令牌秘密(Token Secret)",它应该被共享给收信的第三方。
## 启用启动引导令牌
所有与启动引导令牌相关的特性在 Kubernetes v1.6 版本中默认都是禁用的。
你可以在 API 服务器上通过 `--experimental-bootstrap-token-auth` 参数启用启动引导令牌。
你可以设置控制管理器的 `--controllers` 参数来启用启动引导令牌相关的控制器,例如 `--controllers=*,tokencleaner,bootstrapsigner`
在使用 `kubeadm` 时,这是自动完成的。
HTTPS 调用中的令牌是这样使用的:
```http
Authorization: Bearer 07401b.f395accd246ae52d
```
## 启动引导令牌的密文格式
每个合法的令牌背后对应着 `kube-system` 命名空间中的某个 Secret 对象。
你可以从 [这里](https://git.k8s.io/community/contributors/design-proposals/bootstrap-discovery.md) 找到完整设计文档。
这是 secret 看起来的样子。注意,`base64(string)` 表示应该通过 base64 对值进行编码。
这里使用的是未解码的版本以便于阅读。
```yaml
apiVersion: v1
kind: Secret
metadata:
name: bootstrap-token-07401b
namespace: kube-system
type: bootstrap.kubernetes.io/token
data:
description: base64(The default bootstrap token generated by 'kubeadm init'.)
token-id: base64(07401b)
token-secret: base64(f395accd246ae52d)
expiration: base64(2017-03-10T03:22:11Z)
usage-bootstrap-authentication: base64(true)
usage-bootstrap-signing: base64(true)
```
secret 的类型必须是 `bootstrap.kubernetes.io/token` ,而且名字必须是 `bootstrap-token-<token id>`
`description` 是人类可读的描述,而不应该是机器可读的信息。令牌 ID 和 Secret 是包含在数据字典中的。
`usage-bootstrap-*` 成员表示这个 secret 的用途。启用时,值必须设置为 `true`
`usage-bootstrap-authentication` 表示令牌可以用于 API 服务器的认证。认证器会以
`system:bootstrap:<Token ID>` 认证。它被包含在 `system:bootstrappers` 组中。
命名和组是故意受限制的,以防止用户在启动引导后再使用这些令牌。
`usage-bootstrap-signing` 表示令牌应该被用于 `cluster-info` ConfigMap 的签名,就像下面描述的那样。
`expiration` 数据成员显示了令牌在失效后到现在的时间。这是遵循 RFC3339 进行编码的 UTC 时间。
TokenCleaner 控制器会删除过期的令牌。
## 使用 `kubeadm` 管理令牌
你可以使用 `kubeadm` 工具管理正在运行集群的令牌。它会从 `kubeadm` 创建的集群(`/etc/kubernetes/admin.conf`)
自动抓取默认管理员密码。你可以通过参数 `--kubeconfig` 对下面命令指定一个另外的 kubeconfig 文件抓取密码。
* `kubeadm token list` 列举了令牌,同时显示了它们的过期时间和用途。
* `kubeadm token create` 创建一个新令牌。
* `--description` 设置新令牌的描述。
* `--ttl duration` 设置令牌从 "现在" 起到过期时间的差值。
默认是 0 ,也就是不过期。
* `--usages` 设置令牌被使用的方式。默认是 `signing,authentication`。用途在上面已经描述。
* `kubeadm token delete <token id>|<token id>.<token secret>` 删除令牌。
令牌可以只用 ID 来确认,也可以用整个令牌的值。如果只用 ID 的情况下,密文不匹配的令牌也会被删除。
### ConfigMap签名
除了认证之外,令牌可以用于签名 ConfigMap。这在集群启动过程的早期,在客户端信任 API 服务器之前被使用。
被签名的 ConfigMap 可以通过共享令牌被认证。
被签名的 ConfigMap 是 `cluster-info`,存在于 `kube-public` 命名空间中。
典型的工作流中,客户端在未经认证和忽略 TLS 报错的状态下读取这个 ConfigMap。
通过 ConfigMap 中嵌入的签名校验 ConfigMap 的载荷。
ConfigMap 会是这个样子的:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: cluster-info
namespace: kube-public
data:
jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U
kubeconfig: |
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: <really long certificate data>
server: https://10.138.0.2:6443
name: ""
contexts: []
current-context: ""
kind: Config
preferences: {}
users: []
```
ConfigMap 的 `kubeconfig` 成员是一个填好了集群信息的配置文件。
这里主要交换的信息是 `certificate-authority-data`。在将来可能会有扩展。
签名是一个 JWS 签名,使用了 "detached" 模式。为了检验签名,用户应该按照 JWS 规则
(base64 编码而忽略结尾的 `=`)对 `kubeconfig` 的载荷进行编码。完成编码的载荷会被通过插入 JWS 并存在于两个点的中间
,用于形成一个完整的 JWS。可以使用令牌的完整信息(比如 `07401b.f395accd246ae52d`)作为共享密钥,
通过 `HS256` 方式 (HMAC-SHA256) 对 JWS 进行校验。 用户 _必须_ 确保使用了 HS256。
-122
View File
@@ -1,122 +0,0 @@
---
approvers:
- davidopp
- lavalamp
title: 创建大规模集群
---
## 支持规格
在 {{< param "version" >}}Kubernetes支持最多5000节点规模的集群。 更具体地说,我们支持满足以下 *所有* 标准的配置:
* 不超过5000节点
* 总共不超过15000个pod
* 总共不超过300000个容器
* 每个节点不超过100个pod
<br>
* TOC
{{< toc >}}
## 创建
集群是一组运行Kubernetes代理组件的节点(物理或虚拟机),它们被 "master" (集群管理平面)所管理。
一般来说,集群的节点数量通过平台相关的 `config-default.sh` 文件中的 `NUM_NODES` 值来控制,(例如,详见 [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))。
对很多云提供商来说,单纯地修改`NUM_NODES` 为一个非常大的值,可能会导致集群的创建脚本失败。 例如,在GCE中部署时,会因配额不足,导致集群启动失败。
当建立一个大型的Kubernetes集群,以下几个问题必须考虑。
### 配额问题
为了避免出现配额问题,当创建包含大量节点的集群时,考虑:
* 提高相关配额,如CPUIP等。
* 如,在 [GCE](https://cloud.google.com/compute/docs/resource-quotas)中,你可能需要提高以下资源的配额:
* CPU
* 虚机实例
* 磁盘
* 使用的IP地址
* 防火墙规则
* 转发规则
* 路由
* 对象池
* 设置创建脚本,使其以较小的规模分批次拉起新的节点,并在其间设置一定的等待时间,因为一些云供应商可能对虚机的创建速率进行了限制。
### Etcd存储
为了提升大规模集群的性能,我们将事件对象存储到独立的etcd实例中。
创建集群时,当前的salt脚本:
* 启动并配置额外的etcd实例
* 配置api-server,将该etcd实例用于事件对象的存储
### 管理节点和组件的规格
在 GCE/Google Kubernetes Engine 或 AWS平台中, `kube-up` 会根据集群的节点规模合理地设置管理节点的规格。 在其他云平台上,用户需要手动配置。 作为参考,GCE使用的规格为:
* 1-5 节点: n1-standard-1
* 6-10 节点: n1-standard-2
* 11-100 节点: n1-standard-4
* 101-250 节点: n1-standard-8
* 251-500 节点: n1-standard-16
* 500节点以上: n1-standard-32
AWS使用的规格为:
* 1-5 节点: m3.medium
* 6-10 节点: m3.large
* 11-100 节点: m3.xlarge
* 101-250 节点: m3.2xlarge
* 251-500 节点: c4.4xlarge
* 500节点以上: c4.8xlarge
注意,管理节点的规格只会在集群创建时进行设置,后续集群规模发生变化 (如 手动增删节点或集群自动扩缩容)后不会再调整。
### 插件的资源占用
为防止 [集群插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) 耗尽节点资源引起内存泄漏或其他资源问题, Kubernetes 设置了插件容器资源的上限,来限制其对CPU和内存资源的占用 (参考 PR [#10653](http://pr.k8s.io/10653/files) 和 [#10778](http://pr.k8s.io/10778/files))。
例如:
```yaml
containers:
- name: fluentd-cloud-logging
image: k8s.gcr.io/fluentd-gcp:1.16
resources:
limits:
cpu: 100m
memory: 200Mi
```
除 Heapster 外,这些限制是静态的,基于4个节点规模的集群上运行的插件所采集的数据 (详见 [#10335](http://issue.k8s.io/10335#issuecomment-117861225))。 而实际大规模集群中插件所消耗的资源要多得多 (详见 [#5880](http://issue.k8s.io/5880#issuecomment-113984085))。 所以如果部署大规模集群时不对这些值进行调整,插件可能会因为资源占用达到上限而不断被杀死。
为了避免集群插件的资源问题,创建多节点的集群时,考虑以下几点:
* 当扩大集群规模时,如果涉及,相应扩大以下插件的内存和CPU限制 (通过一个实例处理整个集群,因此其内存和CPU使用量往往与集群的大小/负载成比例增长):
* [InfluxDB 和 Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
* [kubedns, dnsmasq, 和 sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kubedns-controller.yaml.in)
* [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-controller.yaml)
* 当扩大集群规模时,如果涉及,相应扩大以下插件副本数 (每个组件有多个副本,因此增加副本将有助于处理增加的负载,但是,由于每个副本的负载也略有增加,也应考虑提高CPU /内存上限):
* [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-controller.yaml)
* 当扩大集群规模时,如果涉及,略微扩大以下插件的内存和CPU限制 (每个节点一个副本, 但是CPU/内存使用随集群的大小/负载增长变化不明显):
* [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
* [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
Heapster的资源限制是基于集群的初始规模动态设置的 (参考 [#16185](http://issue.k8s.io/16185)
和 [#22940](http://issue.k8s.io/22940))。 当发现Heapster资源耗尽,应考虑调整计算Heapster内存请求的公式 (参考上述PR)。
关于如何检测插件是否达到资源上限 参考 [计算资源的故障排除章节](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting)。
[将来](http://issue.k8s.io/13048),我们期望基于集群规模来设置集群插件的资源限制,并且在集群规模增长或缩小时能够动态调整。
欢迎提出PR来实现这些特性。
### 启动时允许部分失败
因为种种原因 (详见 [#18969](https://github.com/kubernetes/kubernetes/issues/18969)),在 `NUM_NODES` 值很大的情况下执行
`kube-up.sh`, 可能因为其中一小部分节点没有正常启动而失败。
这时我们有两种选择:重启集群 (`kube-down.sh` 然后再 `kube-up.sh`),或者在执行 `kube-up.sh`之前,
将环境变量 `ALLOWED_NOTREADY_NODES` 设置为合适的值。 这将允许 `kube-up.sh` 以少于 `NUM_NODES` 的节点数量启动集群。 依据失败的具体原因,另外的节点可能在后面加入集群,或者集群节点数量将保持在 `NUM_NODES - ALLOWED_NOTREADY_NODES`
@@ -1,214 +0,0 @@
---
title: 构建高可用集群
---
## 简介
本文描述了如何构建一个高可用(high-availability, HA)的Kubernetes集群。这是一个非常高级的主题。
对于仅希望使用Kubernetes进行试验的用户,推荐使用更简单的配置工具进行搭建,例如:
[Minikube](/docs/getting-started-guides/minikube/),或者尝试使用[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 来运行Kubernetes。
此外,当前在我们的端到端(e2e)测试环境中,没有对Kubernetes高可用的支持进行连续测试。我们将会增加这个连续测试项,但当前对单节点master的安装测试得更加严格。
{{< toc >}}
## 概览
搭建一个正真可靠,高度可用的分布式系统需要若干步骤。这类似于穿上内衣,裤子,皮带,背带,另一套内衣和另一套裤子。我们会详细介绍每一个步骤,但先在这里给出一个总结来帮助指导用户。
相关步骤如下:
* [创建可靠的组成节点,共同形成我们的高可用主节点实现。](#可靠的节点)
* [使用etcd集群,搭建一个冗余的,可靠的存储层。](#建立一个冗余的,可靠的存储层)
* [启动具有备份和负载均衡能力的Kubernetes API 服务](#复制的API服务)
* [搭建运行master选举的Kubernetes scheduler和controller-manager守护程序](#进行master选举的组件)
系统完成时看起来应该像这样:
![High availability Kubernetes diagram](/images/docs/ha.svg)
## 初始配置
本文假设你正在搭建一个3节点的主节点集群,每个节点上都运行者某种Linux系统。
指南中的示例使用Debian发行版,但它们应该可以被轻松移植到其他发行版上。
同样的,不管在公有云还是私有云亦或是裸机上,这个配置都应该可以运行。
从一个现成的单主节点集群开始是实现一个高可用Kubernetes集群的最简单的方法。这篇指导 [https://get.k8s.io](https://get.k8s.io) 描述了在多种平台上方便的安装一个单主节点集群的方法。
## 可靠的节点
我们在每个主节点上都将运行数个实现Kubernetes API的进程。使他们可靠的第一步是保证在发生故障时,每一个进程都可以自动重启。为了实现这个目标,我们需要安装一个进程监视器。我们选择了在每个工作者节点上都会运行的`kubelet`进程。这会带来便利性,因为我们使用了容器来分发我们的二进制文件,所以我们能够为每一个守护程序建立资源限制并省查它们的资源消耗。当然,我们也需要一些手段来监控kubelete本身(在此监测监控者本身是一个有趣的话题)。对于Debian系统我们选择了monit,但也有许多可替代的工具。例如在基于systemd的系统上(如RHEL, CentOS),你可以运行 'systemctl enable kubelet'。
如果你是从标准的Kubernetes安装扩展而来,那么`kubelet`二进制文件应该已经存在于你的系统中。你可以运行`which kubelet`来判断是否确实安装了这个二进制文件。如果没有安装的话,你应该手动安装 [kubelet binary](https://storage.googleapis.com/kubernetes-release/release/v0.19.3/bin/linux/amd64/kubelet),
[kubelet init file](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/saltbase/salt/kubelet/initd) 和 [default-kubelet](/docs/admin/high-availability/default-kubelet)脚本。
如果使用monit,你还需要安装monit守护程序(`apt-get install monit`)以及[monit-kubelet](/docs/admin/high-availability/monit-kubelet) 和
[monit-docker](/docs/admin/high-availability/monit-docker) 配置。
在使用systemd的系统上,你可以执行 `systemctl enable kubelet``systemctl enable docker`
## 建立一个冗余的,可靠的存储层
高可用方案的中心基础是一个冗余的,可靠的存储层。高可用的头条规则是保护数据。不管发生了什么,不管什么着了火,只要还有数据,你就可以重建。如果丢掉了数据,你就完了。
集群化的etcd已经把你存储的数据复制到了你集群中的所有主节点实例上。这意味着如果要想丢失数据,三个节点的物理(或虚拟)硬盘需要全部同时故障。这种情况发生的概率是比较低的,所以对于许多人来说,运行一个复制的etcd集群可能已经足够的可靠了。你可以将集群数量从3个增大到5个来增加集群的可靠性。如果那样还不够,你可以添加[更多的可靠性到你的存储层](#更加可靠的存储)。
### 集群化etcd
集群化etcd的完整细节超出了本文范围,你可以在[etcd clustering page](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md)找到许多详细内容。这个例子仅走查一个简单的集群建立过程,使用etcd内置的发现功能来构建我们的集群。
首先,调用etcd发现服务来创建一个新令牌:
```shell
curl https://discovery.etcd.io/new?size=3
```
在每个节点上,拷贝 [etcd.yaml](/docs/admin/high-availability/etcd.yaml) 文件到`/etc/kubernetes/manifests/etcd.yaml`
每个节点上的kubelet会动态的监控这个文件夹的内容,并且会按照`etcd.yaml`里对pod的定义创建一个`etcd`服务的实例。
请注意,你应该使用上文中获取的令牌URL替换全部三个节点上`etcd.yaml`中的`${DISCOVERY_TOKEN}`项。同时还应该将每个节点上的 `${NODE_NAME}`替换为一个不同的名字(例如:`node-1`),并将 `${NODE_IP}`替换为正确的IP地址。
#### 验证你的集群
如果已经将这个文件拷贝到所有三个节点,你应该已经搭建起了一个集群化的etcd。你可以在主节点上进行验证:
```shell
kubectl exec < pod_name > etcdctl member list
```
```shell
kubectl exec < pod_name > etcdctl cluster-health
```
你也可以在一个节点上运行 `etcdctl set foo bar`,在另一个节点上运行`etcdctl get foo`来验证集群是否工作正常。
### 更加可靠的存储
当然,如果你对增加数据的可靠性感兴趣,这里还有一些更深入的选项可以使etcd把它的数据存放在比常规硬盘更可靠的地方(裤带和背带,ftw!)。
如果你使用云服务,那么你的提供商通常会为你提供这个特性,例如Google Cloud Platform上的 [Persistent Disk](https://cloud.google.com/compute/docs/disks/persistent-disks) 。它们是可以挂载到你的虚拟机中的块设备持久化存储。其他的云服务提供商提供了类似的解决方案。
如果运行于物理机之上,你仍然可以使用iSCSI或者NFS接口通过网络来连接冗余存储。
此外,你还可以运行一个集群文件系统,比如Gluster或者Ceph。最后,你还可以在你的每个物理机器上运行RAID矩阵。
不管你选择如何实现,如果已经选择了使用其中的一个选项,那么你应该保证你的存储被挂载到了每一台机器上。如果你的存储在集群中的三个主节点之间共享,那么你应该在存储上为每一个节点创建一个不同的文件夹。对于所有的这些指导,我们都假设这个存储被挂载到你机器上的`/var/etcd/data`路径。
## 复制的API服务
在正确搭建复制的etcd之后,我们还需要使用kubelet安装apiserver。
首先,你需要创建初始的日志文件,这样Docker才会挂载一个文件而不是一个文件夹:
```shell
touch /var/log/kube-apiserver.log
```
接下来,你需要在每个节点上创建一个`/srv/kubernetes/`文件夹。这个文件夹包含:
* basic_auth.csv - 基本认证的用户名和密码
* ca.crt - CA证书
* known_tokens.csv - 实体(例如kubelet)用来和apiserver通信的令牌
* kubecfg.crt - 客户端证书,公钥
* kubecfg.key - 客户端证书,私钥
* server.cert - 服务端证书,公钥
* server.key - 服务端证书,私钥
创建这个文件夹最简单的方法可以是从一个工作正常的集群的主节点拷贝,或者你也可以手动生成它们。
### 启动API服务
一旦这些文件已经存在了,拷贝 [kube-apiserver.yaml](/docs/admin/high-availability/kube-apiserver.yaml) 到每个主节点的 `/etc/kubernetes/manifests/`文件夹。
kubelet会监控这个文件夹,并且会按照文件里对pod的定义创建一个`kube-apiserver`容器。
### 负载均衡
现在,你应该有3个全部正常工作的apiserver了。如果搭建了网络负载均衡器,你应该能够通过那个负载均衡器访问你的集群,并且看到负载在apiserver实例间分发。设置负载均衡器依赖于你的平台的实际情况,例如对于Google Cloud Platform的指导可以在[这里](https://cloud.google.com/compute/docs/load-balancing/)找到。
请注意,如果使用了身份认证,你可能需要重新生成你的证书,除每个节点的IP地址外额外包含负载均衡器的IP地址。
对于部署在集群中的pods `kubernetes`服务/dns名称应该自动的为主节点提供了负载均衡的endpoint。
对于使用API的外部用户(如命令行运行的`kubectl`,持续集成管道或其他客户端)你会希望将他们配置成为访问外部负载均衡器的地址。
## 进行Master选举的组件
到目前为止,我们已经搭建了状态存储,也搭建好了API服务,但我们还没有运行任何真正改变集群状态的服务,比如controller manager和scheduler。为了可靠的实现这个目标,我们希望在同一时间只有一个参与者在修改集群状态。但是我们希望复制这些参与者的实例以防某个机器宕机。要做到这一点,我们打算在API中使用一个lease-lock来执行master选举。我们会对每一个scheduler和controller-manager使用`--leader-elect`标志,从而在API中使用一个租约来保证同一时间只有一个scheduler和controller-manager的实例正在运行。
scheduler和controller-manager可以配置为只和位于它们相同节点(即127.0.0.1)上的API服务通信,也可以配置为使用API服务的负载均衡器的IP地址。不管它们如何配置,当使用`--leader-elect` 时scheduler和controller-manager都将完成上文提到的leader选举过程。
为了防止访问API服务失败,选举出的leader不能通过更新租约来选举一个新的leader。当scheduler和controller-manager通过127.0.0.1访问API服务,而相同节点上的API服务不可用时,这一点相当重要。
### 安装配置文件
首先,在每个节点上创建空白日志文件,这样Docker就会挂载这些文件而不是创建一个新文件夹:
```shell
touch /var/log/kube-scheduler.log
touch /var/log/kube-controller-manager.log
```
接下来,在每个节点上配置scheduler和controller manager pods的描述文件。拷贝 [kube-scheduler.yaml](/docs/admin/high-availability/kube-scheduler.yaml) 和 [kube-controller-manager.yaml](/docs/admin/high-availability/kube-controller-manager.yaml) 到`/etc/kubernetes/manifests/` 文件夹。
## 结尾
此时,你已经完成了master组件的配置(耶!),但你还需要添加工作者节点(噗!)。
如果你有一个现成的集群,你只需要在每个节点上简单的重新配置你的kubeletes连接到负载均衡的endpoint并重启它们。
如果你搭建的是一个全新的集群,你将需要在每个工作节点上安装kubelet和kube-proxy,并设置 `--apiserver`指向复制的endpoint。
-229
View File
@@ -1,229 +0,0 @@
---
title: kube-apiserver
notitle: true
---
## kube-apiserver
### 概要
Kubernetes API server 为 api 对象验证并配置数据,包括 pods、 services、 replicationcontrollers和其它 api 对象。API Server 提供 REST 操作和到集群共享状态的前端,所有其他组件通过它进行交互。
```
kube-apiserver
```
### 选项
```
--admission-control stringSlice 控制资源进入集群的准入控制插件的顺序列表。逗号分隔的NamespaceLifecycle列表。(默认值[AlwaysAdmit])
--admission-control-config-file string 包含准入控制配置的文件。
--advertise-address ip 向集群成员通知apiserver消息的IP地址。这个地址必须能够被集群中其他成员访问。如果IP地址为空,将会使用--bind-address,如果未指定--bind-address,将会使用主机的默认接口地址。
--allow-privileged 如果为true, 将允许特权容器.
--anonymous-auth 启用到API server的安全端口的匿名请求。未被其他认证方法拒绝的请求被当做匿名请求。匿名请求的用户名为system:anonymous,用户组名为system:unauthenticated。(默认值true
--apiserver-count int 集群中运行的apiserver数量,必须为正数。(默认值1)
--audit-log-maxage int 基于文件名中的时间戳,旧审计日志文件的最长保留天数。
--audit-log-maxbackup int 旧审计日志文件的最大保留个数.
--audit-log-maxsize int 审计日志被轮转前的最大兆字节数。
--audit-log-path string 如果设置该值,所有到apiserver的请求都将会被记录到这个文件。'-'表示记录到标准输出。
--audit-policy-file string 定义审计策略配置的文件的路径。需要打开'AdvancedAuditing'特性开关。AdvancedAuditing需要一个配置来启用审计功能。
--audit-webhook-config-file string 一个具有kubeconfig格式文件的路径,该文件定义了审计的webhook配置。需要打开'AdvancedAuditing'特性开关。
--audit-webhook-mode string 发送审计事件的策略。 Blocking模式表示正在发送事件时应该阻塞服务器的响应。 Batch模式使webhook异步缓存和发送事件。 Known模式为batch,blocking。 (默认值"batch")
--authentication-token-webhook-cache-ttl duration 从webhook令牌认证者获取的响应的缓存时长。(默认值2m0s)
--authentication-token-webhook-config-file string 包含webhook配置的文件,用于令牌认证,具有kubeconfig格式。API server将查询远程服务来决定对bearer令牌的认证。
--authorization-mode string 在安全端口上进行权限验证的插件的顺序列表。以逗号分隔的列表,包括:AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node.(默认值"AlwaysAllow"
--authorization-policy-file string 包含权限验证策略的csv文件,和--authorization-mode=ABAC一起使用,作用在安全端口上。
--authorization-webhook-cache-authorized-ttl duration 从webhook授权者获得的'authorized'响应的缓存时长。(默认值5m0s)
--authorization-webhook-cache-unauthorized-ttl duration 从webhook授权者获得的'unauthorized'响应的缓存时长。(默认值30s)
--authorization-webhook-config-file string 包含webhook配置的kubeconfig格式文件,和--authorization-mode=Webhook一起使用。API server将查询远程服务来决定对API server安全端口的访问。
--azure-container-registry-config string 包含Azure容器注册表配置信息的文件的路径。
--basic-auth-file string 如果设置该值,这个文件将会被用于准许通过http基本认证到API server安全端口的请求。
--bind-address ip 监听--seure-port的IP地址。被关联的接口必须能够被集群其它节点和CLI/web客户端访问。如果为空,则将使用所有接口(0.0.0.0)。(默认值0.0.0.0
--cert-dir string 存放TLS证书的目录。如果提供了--tls-cert-file和--tls-private-key-file选项,该标志将被忽略。(默认值 "/var/run/kubernetes"
--client-ca-file string 如果设置此标志,对于任何请求,如果存包含client-ca-file中的authorities签名的客户端证书,将会使用客户端证书中的CommonName对应的身份进行认证。
--cloud-config string 云服务提供商配置文件路径。空字符串表示无配置文件.
--cloud-provider string 云服务提供商,空字符串表示无提供商。
--contention-profiling 如果已经启用profiling,则启用锁竞争profiling。
--cors-allowed-origins stringSlice CORS的域列表,以逗号分隔。合法的域可以是一个匹配子域名的正则表达式。如果这个列表为空则不会启用CORS.
--delete-collection-workers int 用于DeleteCollection调用的工作者数量。这被用于加速namespace的清理。(默认值1)
--deserialization-cache-size int 在内存中缓存的反序列化json对象的数量。
--enable-aggregator-routing 打开到endpoints IP的aggregator路由请求,替换cluster IP。
--enable-garbage-collector 启用通用垃圾回收器. 必须与kube-controller-manager对应的标志保持同步。 (默认值true)
--enable-logs-handler 如果为true,则为apiserver日志功能安装一个/logs处理器。(默认值true)
--enable-swagger-ui 在apiserver的/swagger-ui路径启用swagger ui。
--etcd-cafile string 用于保护etcd通信的SSL CA文件。
--etcd-certfile string 用于保护etcd通信的的SSL证书文件。
--etcd-keyfile string 用于保护etcd通信的SSL密钥文件.
--etcd-prefix string 附加到所有etcd中资源路径的前缀。 (默认值"/registry"
--etcd-quorum-read 如果为true, 启用quorum读。
--etcd-servers stringSlice 连接的etcd服务器列表,形式为(scheme://ip:port),使用逗号分隔。
--etcd-servers-overrides stringSlice 针对单个资源的etcd服务器覆盖配置, 以逗号分隔。 单个配置覆盖格式为: group/resource#servers, 其中servers形式为http://ip:port, 以分号分隔。
--event-ttl duration 事件驻留时间。(默认值1h0m0s)
--experimental-bootstrap-token-auth 启用此选项以允许'kube-system'命名空间中的'bootstrap.kubernetes.io/token'类型密钥可以被用于TLS的启动认证。
--experimental-encryption-provider-config string 包含加密提供程序的配置的文件,该加密提供程序被用于在etcd中保存密钥。
--external-hostname string 为此master生成外部URL时使用的主机名(例如Swagger API文档)。
--feature-gates mapStringBool 一个描述alpha/experimental特性开关的键值对列表。 选项包括:
Accelerators=true|false (ALPHA - default=false)
AdvancedAuditing=true|false (ALPHA - default=false)
AffinityInAnnotations=true|false (ALPHA - default=false)
AllAlpha=true|false (ALPHA - default=false)
AllowExtTrafficLocalEndpoints=true|false (default=true)
AppArmor=true|false (BETA - default=true)
DynamicKubeletConfig=true|false (ALPHA - default=false)
DynamicVolumeProvisioning=true|false (ALPHA - default=true)
ExperimentalCriticalPodAnnotation=true|false (ALPHA - default=false)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
LocalStorageCapacityIsolation=true|false (ALPHA - default=false)
PersistentLocalVolumes=true|false (ALPHA - default=false)
RotateKubeletClientCertificate=true|false (ALPHA - default=false)
RotateKubeletServerCertificate=true|false (ALPHA - default=false)
StreamingProxyRedirects=true|false (BETA - default=true)
TaintBasedEvictions=true|false (ALPHA - default=false)
--google-json-key string 用于认证的Google Cloud Platform服务账号的JSON密钥。
--insecure-allow-any-token username/group1,group2 如果设置该值, 你的服务将处于非安全状态。任何令牌都将会被允许,并将从令牌中把用户信息解析成为username/group1,group2。
--insecure-bind-address ip 用于监听--insecure-port的IP地址 (设置成0.0.0.0表示监听所有接口)。(默认值127.0.0.1)
--insecure-port int 用于监听不安全和为认证访问的端口。这个配置假设你已经设置了防火墙规则,使得这个端口不能从集群外访问。对集群的公共地址的443端口的访问将被代理到这个端口。默认设置中使用nginx实现。(默认值8080)
--kubelet-certificate-authority string 证书authority的文件路径。
--kubelet-client-certificate string 用于TLS的客户端证书文件路径。
--kubelet-client-key string 用于TLS的客户端证书密钥文件路径.
--kubelet-https 为kubelet启用https。 (默认值true
--kubelet-preferred-address-types stringSlice 用于kubelet连接的首选NodeAddressTypes列表。 (默认值[Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP])
--kubelet-read-only-port uint 已废弃: kubelet端口. (默认值10255
--kubelet-timeout duration kubelet操作超时时间。(默认值
5s
--kubernetes-service-node-port int 如果不为0Kubernetes master服务(用于创建/管理apiserver)将会使用NodePort类型,并将这个值作为端口号。如果为0,Kubernetes master服务将会使用ClusterIP类型。
--master-service-namespace string 已废弃: 注入到pod中的kubernetes master服务的命名空间。(默认值"default"
--max-connection-bytes-per-sec int 如果不为0,每个用户连接将会被限速为该值(bytes/sec)。当前只应用于长时间运行的请求。
--max-mutating-requests-inflight int 在给定时间内进行中可变请求的最大数量。当超过该值时,服务将拒绝所有请求。0值表示没有限制。(默认值200)
--max-requests-inflight int 在给定时间内进行中不可变请求的最大数量。当超过该值时,服务将拒绝所有请求。0值表示没有限制。(默认值400)
--min-request-timeout int 一个可选字段,表示一个handler在一个请求超时前,必须保持它处于打开状态的最小秒数。当前只对监听请求handler有效,它基于这个值选择一个随机数作为连接超时值,以达到分散负载的目的(默认值1800)。
--oidc-ca-file string 如果设置该值,将会使用oidc-ca-file中的任意一个authority对OpenID服务的证书进行验证,否则将会使用主机的根CA对其进行验证。
--oidc-client-id string 使用OpenID连接的客户端的ID,如果设置了oidc-issuer-url,则必须设置这个值。
--oidc-groups-claim string 如果提供该值,这个自定义OpenID连接名将指定给特定的用户组。该声明值需要是一个字符串或字符串数组。此标志为实验性的,请查阅验证相关文档进一步了解详细信息。
--oidc-issuer-url string OpenID颁发者URL,只接受HTTPS方案。如果设置该值,它将被用于验证OIDC JSON Web Token(JWT)。
--oidc-username-claim string 用作用户名的OpenID声明值。注意,不保证除默认 ('sub')外的其他声明值的唯一性和不变性。此标志为实验性的,请查阅验证相关文档进一步了解详细信息。
--profiling 在web接口host:port/debug/pprof/上启用profiling。(默认值true
--proxy-client-cert-file string 当必须调用外部程序时,用于证明aggregator或者kube-apiserver的身份的客户端证书。包括代理到用户api-server的请求和调用webhook准入控制插件的请求。它期望这个证书包含一个来自于CA中的--requestheader-client-ca-file标记的签名。该CA在kube-system命名空间的'extension-apiserver-authentication' configmap中发布。从Kube-aggregator收到调用的组件应该使用该CA进行他们部分的双向TLS验证。
--proxy-client-key-file string 当必须调用外部程序时,用于证明aggregator或者kube-apiserver的身份的客户端证书密钥。包括代理到用户api-server的请求和调用webhook准入控制插件的请求。
--repair-malformed-updates 如果为true,服务将会尽力修复更新请求以通过验证,例如:将更新请求UID的当前值设置为空。在我们修复了所有发送错误格式请求的客户端后,可以关闭这个标志。
--requestheader-allowed-names stringSlice 使用--requestheader-username-headers指定的,允许在头部提供用户名的客户端证书通用名称列表。如果为空,任何通过--requestheader-client-ca-file中authorities验证的客户端证书都是被允许的。
--requestheader-client-ca-file string 在信任请求头中以--requestheader-username-headers指示的用户名之前,用于验证接入请求中客户端证书的根证书捆绑。
--requestheader-extra-headers-prefix stringSlice 用于检查的请求头的前缀列表。建议使用X-Remote-Extra-。
--requestheader-group-headers stringSlice 用于检查群组的请求头列表。建议使用X-Remote-Group.
--requestheader-username-headers stringSlice 用于检查用户名的请求头列表。建议使用X-Remote-User。
--runtime-config mapStringString 传递给apiserver用于描述运行时配置的键值对集合。 apis/<groupVersion>键可以被用来打开/关闭特定的api版本。apis/<groupVersion>/<resource>键被用来打开/关闭特定的资源. api/all和api/legacy键分别用于控制所有的和遗留的api版本.
--secure-port int 用于监听具有认证授权功能的HTTPS协议的端口。如果为0,则不会监听HTTPS协议。 (默认值6443)
--service-account-key-file stringArray 包含PEM加密的x509 RSA或ECDSA私钥或公钥的文件,用于验证ServiceAccount令牌。如果设置该值,--tls-private-key-file将会被使用。指定的文件可以包含多个密钥,并且这个标志可以和不同的文件一起多次使用。
--service-cluster-ip-range ipNet CIDR表示的IP范围,服务的cluster ip将从中分配。 一定不要和分配给nodes和pods的IP范围产生重叠。
--ssh-keyfile string 如果不为空,在使用安全的SSH代理访问节点时,将这个文件作为用户密钥文件。
--storage-backend string 持久化存储后端。 选项为: 'etcd3' (默认), 'etcd2'.
--storage-media-type string 在存储中保存对象的媒体类型。某些资源或者存储后端可能仅支持特定的媒体类型,并且忽略该配置项。(默认值 "application/vnd.kubernetes.protobuf")
--storage-versions string 按组划分资源存储的版本。 以"group1/version1,group2/version2,..."的格式指定。当对象从一组移动到另一组时, 你可以指定"group1=group2/v1beta1,group3/v1beta1,..."的格式。你只需要传入你希望从结果中改变的组的列表。默认为从KUBE_API_VERSIONS环境变量集成而来,所有注册组的首选版本列表。 (默认值"admission.k8s.io/v1alpha1,admissionregistration.k8s.io/v1alpha1,apps/v1beta1,authentication.k8s.io/v1,authorization.k8s.io/v1,autoscaling/v1,batch/v1,certificates.k8s.io/v1beta1,componentconfig/v1alpha1,extensions/v1beta1,federation/v1beta1,imagepolicy.k8s.io/v1alpha1,networking.k8s.io/v1,policy/v1beta1,rbac.authorization.k8s.io/v1beta1,settings.k8s.io/v1alpha1,storage.k8s.io/v1,v1")
--target-ram-mb int apiserver内存限制,单位为MB(用于配置缓存大小等)。
--tls-ca-file string 如果设置该值,这个证书authority将会被用于从Admission Controllers过来的安全访问。它必须是一个PEM加密的合法CA捆绑包。此外, 该证书authority可以被添加到以--tls-cert-file提供的证书文件中.
--tls-cert-file string 包含用于HTTPS的默认x509证书的文件。(如果有CA证书,则附加于server证书之后)。如果启用了HTTPS服务,并且没有提供--tls-cert-file和--tls-private-key-file,则将为公共地址生成一个自签名的证书和密钥并保存于/var/run/kubernetes目录。
--tls-private-key-file string 包含匹配--tls-cert-file的x509证书私钥的文件。
--tls-sni-cert-key namedCertKey 一对x509证书和私钥的文件路径, 可以使用符合正式域名的域形式作为后缀。 如果没有提供域形式后缀, 则将提取证书名。 非通配符版本优先于通配符版本, 显示的域形式优先于证书中提取的名字。 对于多个密钥/证书对, 请多次使用--tls-sni-cert-key。例如: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". (默认值[])
--token-auth-file string 如果设置该值,这个文件将被用于通过令牌认证来保护API服务的安全端口。
--version version[=true] 打印版本信息并退出。
--watch-cache 启用apiserver的监视缓存。(默认值true)
--watch-cache-sizes stringSlice 每种资源(pods, nodes等)的监视缓存大小列表,以逗号分隔。每个缓存配置的形式为:resource#sizesize是一个数字。在watch-cache启用时生效。
```
###### Auto generated by spf13/cobra on 11-Jul-2017
@@ -1,86 +0,0 @@
---
approvers:
- liggitt
title: Kubelet authentication/authorization
---
{{< toc >}}
## Overview
A kubelet's HTTPS endpoint exposes APIs which give access to data of varying sensitivity,
and allow you to perform operations with varying levels of power on the node and within containers.
This document describes how to authenticate and authorize access to the kubelet's HTTPS endpoint.
## Kubelet authentication
By default, requests to the kubelet's HTTPS endpoint that are not rejected by other configured
authentication methods are treated as anonymous requests, and given a username of `system:anonymous`
and a group of `system:unauthenticated`.
To disable anonymous access and send `401 Unauthorized` responses to unauthenticated requests:
* start the kubelet with the `--anonymous-auth=false` flag
To enable X509 client certificate authentication to the kubelet's HTTPS endpoint:
* start the kubelet with the `--client-ca-file` flag, providing a CA bundle to verify client certificates with
* start the apiserver with `--kubelet-client-certificate` and `--kubelet-client-key` flags
* see the [apiserver authentication documentation](/docs/admin/authentication/#x509-client-certs) for more details
To enable API bearer tokens (including service account tokens) to be used to authenticate to the kubelet's HTTPS endpoint:
* ensure the `authentication.k8s.io/v1beta1` API group is enabled in the API server
* start the kubelet with the `--authentication-token-webhook` and the `--kubeconfig` flags
* the kubelet calls the `TokenReview` API on the configured API server to determine user information from bearer tokens
## Kubelet authorization
Any request that is successfully authenticated (including an anonymous request) is then authorized. The default authorization mode is `AlwaysAllow`, which allows all requests.
There are many possible reasons to subdivide access to the kubelet API:
* anonymous auth is enabled, but anonymous users' ability to call the kubelet API should be limited
* bearer token auth is enabled, but arbitrary API users' (like service accounts) ability to call the kubelet API should be limited
* client certificate auth is enabled, but only some of the client certificates signed by the configured CA should be allowed to use the kubelet API
To subdivide access to the kubelet API, delegate authorization to the API server:
* ensure the `authorization.k8s.io/v1beta1` API group is enabled in the API server
* start the kubelet with the `--authorization-mode=Webhook` and the `--kubeconfig` flags
* the kubelet calls the `SubjectAccessReview` API on the configured API server to determine whether each request is authorized
The kubelet authorizes API requests using the same [request attributes](/docs/admin/authorization/#request-attributes) approach as the apiserver.
The verb is determined from the incoming request's HTTP verb:
HTTP verb | request verb
----------|---------------
POST | create
GET, HEAD | get
PUT | update
PATCH | patch
DELETE | delete
The resource and subresource is determined from the incoming request's path:
Kubelet API | resource | subresource
-------------|----------|------------
/stats/\* | nodes | stats
/metrics/\* | nodes | metrics
/logs/\* | nodes | log
/spec/\* | nodes | spec
*all others* | nodes | proxy
The namespace and API group attributes are always an empty string, and
the resource name is always the name of the kubelet's `Node` API object.
When running in this mode, ensure the user identified by the `--kubelet-client-certificate` and `--kubelet-client-key`
flags passed to the apiserver is authorized for the following attributes:
* verb=\*, resource=nodes, subresource=proxy
* verb=\*, resource=nodes, subresource=stats
* verb=\*, resource=nodes, subresource=log
* verb=\*, resource=nodes, subresource=spec
* verb=\*, resource=nodes, subresource=metrics
@@ -1,214 +0,0 @@
---
approvers:
- ericchiang
- mikedanese
- jcbsmpsn
title: TLS bootstrapping
---
{{< toc >}}
## Overview
This document describes how to set up TLS client certificate bootstrapping for kubelets.
Kubernetes 1.4 introduced an API for requesting certificates from a cluster-level Certificate Authority (CA). The original intent of this API is to enable provisioning of TLS client certificates for kubelets. The proposal can be found [here](https://github.com/kubernetes/kubernetes/pull/20439)
and progress on the feature is being tracked as [feature #43](https://github.com/kubernetes/features/issues/43).
## kube-apiserver configuration
The API server should be configured with an [authenticator](/docs/admin/authentication/) that can authenticate tokens as a user in the `system:bootstrappers` group.
This group will later be used in the controller-manager configuration to scope approvals in the default approval
controller. As this feature matures, you should ensure tokens are bound to a Role-Based Access Control (RBAC) policy which limits requests
(using the bootstrap token) strictly to client requests related to certificate provisioning. With RBAC in place, scoping the tokens to a group allows for great flexibility (e.g. you could disable a particular bootstrap group's access when you are done provisioning the nodes).
While any authentication strategy can be used for the kubelet's initial bootstrap credentials, the following two authenticators are recommended for ease of provisioning.
1. [Bootstrap Tokens](/docs/admin/bootstrap-tokens/) - __alpha__
2. [Token authentication file](###token-authentication-file)
Using bootstrap tokens is currently __alpha__ and will simplify the management of bootstrap token management especially in a HA scenario.
### Token authentication file
Tokens are arbitrary but should represent at least 128 bits of entropy derived from a secure random number
generator (such as /dev/urandom on most modern systems). There are multiple ways you can generate a token. For example:
`head -c 16 /dev/urandom | od -An -t x | tr -d ' '`
will generate tokens that look like `02b50b05283e98dd0fd71db496ef01e8`
The token file should look like the following example, where the first three values can be anything and the quoted group
name should be as depicted:
```
02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:bootstrappers"
```
Add the `--token-auth-file=FILENAME` flag to the kube-apiserver command (in your systemd unit file perhaps) to enable the token file.
See docs [here](/docs/admin/authentication/#static-token-file) for further details.
### Client certificate CA bundle
Add the `--client-ca-file=FILENAME` flag to the kube-apiserver command to enable client certificate authentication,
referencing a certificate authority bundle containing the signing certificate (e.g. `--client-ca-file=/var/lib/kubernetes/ca.pem`).
## kube-controller-manager configuration
The API for requesting certificates adds a certificate-issuing control loop to the Kubernetes Controller Manager. This takes the form of a
[cfssl](https://blog.cloudflare.com/introducing-cfssl/) local signer using assets on disk. Currently, all certificates issued have one year validity and a default set of key usages.
### Signing assets
You must provide a Certificate Authority in order to provide the cryptographic materials necessary to issue certificates.
This CA should be trusted by kube-apiserver for authentication with the `--client-ca-file=FILENAME` flag. The management
of the CA is beyond the scope of this document but it is recommended that you generate a dedicated CA for Kubernetes.
Both certificate and key are assumed to be PEM-encoded.
The kube-controller-manager flags are:
```
--cluster-signing-cert-file="/etc/path/to/kubernetes/ca/ca.crt" --cluster-signing-key-file="/etc/path/to/kubernetes/ca/ca.key"
```
### Approval controller
In 1.7 the experimental "group auto approver" controller is dropped in favor of the new `csrapproving` controller
that ships as part of [kube-controller-manager](/docs/admin/kube-controller-manager/) and is enabled by default.
The controller uses the [`SubjectAccessReview` API](/docs/admin/authorization/#checking-api-access) to determine
if a given user is authorized to request a CSR, then approves based on the authorization outcome. To prevent
conflicts with other approvers, the builtin approver doesn't explicitly deny CSRs, only ignoring unauthorized requests.
The controller categorizes CSRs into three subresources:
1. `nodeclient` - a request by a user for a client certificate with `O=system:nodes` and `CN=system:node:(node name)`.
2. `selfnodeclient` - a node renewing a client certificate with the same `O` and `CN`.
3. `selfnodeserver` - a node renewing a serving certificate. (ALPHA, requires feature gate)
The checks to determine if a CSR is a `selfnodeserver` request is currently tied to the kubelet's credential rotation
implementation, an __alpha__ feature. As such, the definition of `selfnodeserver` will likely change in a future and
requires the `RotateKubeletServerCertificate` feature gate on the controller manager. The feature progress can be
tracked at [kubernetes/features#267](https://github.com/kubernetes/features/issues/267).
```
--feature-gates=RotateKubeletServerCertificate=true
```
The following RBAC `ClusterRoles` represent the `nodeclient`, `selfnodeclient`, and `selfnodeserver` capabilities. Similar roles
may be automatically created in future releases.
```yml
# A ClusterRole which instructs the CSR approver to approve a user requesting
# node client credentials.
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: approve-node-client-csr
rules:
- apiGroups: ["certificates.k8s.io"]
resources: ["certificatesigningrequests/nodeclient"]
verbs: ["create"]
---
# A ClusterRole which instructs the CSR approver to approve a node renewing its
# own client credentials.
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: approve-node-client-renewal-csr
rules:
- apiGroups: ["certificates.k8s.io"]
resources: ["certificatesigningrequests/selfnodeclient"]
verbs: ["create"]
---
# A ClusterRole which instructs the CSR approver to approve a node requesting a
# serving cert matching its client cert.
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: approve-node-server-renewal-csr
rules:
- apiGroups: ["certificates.k8s.io"]
resources: ["certificatesigningrequests/selfnodeserver"]
verbs: ["create"]
```
These powers can be granted to credentials, such as bootstrapping tokens. For example, to replicate the behavior
provided by the removed auto-approval flag, of approving all CSRs by a single group:
```
# REMOVED: This flag no longer works as of 1.7.
--insecure-experimental-approve-all-kubelet-csrs-for-group="system:bootstrappers"
```
An admin would create a `ClusterRoleBinding` targeting that group.
```yml
# Approve all CSRs for the group "system:bootstrappers"
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: auto-approve-csrs-for-group
subjects:
- kind: Group
name: system:bootstrappers
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: approve-node-client-csr
apiGroup: rbac.authorization.k8s.io
```
To let a node renew its own credentials, an admin can construct a `ClusterRoleBinding` targeting
that node's credentials:
```yml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: node1-client-cert-renewal
subjects:
- kind: User
name: system:node:node-1 # Let "node-1" renew its client certificate.
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: approve-node-client-renewal-csr
apiGroup: rbac.authorization.k8s.io
```
Deleting the binding will prevent the node from renewing its client credentials, effectively
removing it from the cluster once its certificate expires.
## kubelet configuration
To request a client certificate from kube-apiserver, the kubelet first needs a path to a kubeconfig file that contains the
bootstrap authentication token. You can use `kubectl config set-cluster`, `set-credentials`, and `set-context` to build this kubeconfig. Provide the name `kubelet-bootstrap` to `kubectl config set-credentials` and include `--token=<token-value>` as follows:
```
kubectl config set-credentials kubelet-bootstrap --token=${BOOTSTRAP_TOKEN} --kubeconfig=bootstrap.kubeconfig
```
When starting the kubelet, if the file specified by `--kubeconfig` does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On approval of the certificate request and receipt back by the kubelet, a kubeconfig file referencing the generated key and obtained certificate is written to the path specified by `--kubeconfig`. The certificate and key file will be placed in the directory specified by `--cert-dir`.
**Note:** The following flags are required to enable this bootstrapping when starting the kubelet:
```
--bootstrap-kubeconfig="/path/to/bootstrap/kubeconfig"
```
Additionally, in 1.7 the kubelet implements __alpha__ features for enabling rotation of both its client and/or serving certs.
These can be enabled through the respective `RotateKubeletClientCertificate` and `RotateKubeletServerCertificate` feature
flags on the kubelet, but may change in backward incompatible ways in future releases.
```
--feature-gates=RotateKubeletClientCertificate=true,RotateKubeletServerCertificate=true
```
`RotateKubeletClientCertificate` causes the kubelet to rotate its client certificates by creating new CSRs as its existing
credentials expire. `RotateKubeletServerCertificate` causes the kubelet to both request a serving certificate after
bootstrapping its client credentials and rotate the certificate. The serving cert currently does not request DNS or IP
SANs.
## kubectl approval
The signing controller does not immediately sign all certificate requests. Instead, it waits until they have been flagged with an
"Approved" status by an appropriately-privileged user. This is intended to eventually be an automated process handled by an external
approval controller, but for the alpha version of the API it can be done manually by a cluster administrator using kubectl.
An administrator can list CSRs with `kubectl get csr` and describe one in detail with `kubectl describe csr <name>`. Before the 1.6 release there were
[no direct approve/deny commands](https://github.com/kubernetes/kubernetes/issues/30163) so an approver had to update
the Status field directly ([rough how-to](https://github.com/gtank/csrctl)). Later versions of Kubernetes offer `kubectl certificate approve <name>` and `kubectl certificate deny <name>` commands.
-291
View File
@@ -1,291 +0,0 @@
---
approvers:
- jlowdermilk
- justinsb
- quinton-hoole
title: 多区域运行
---
## 介绍
Kubernetes 从v1.2开始支持将集群运行在多个故障域中。
(GCE 中称其为 "区(Zones" AWS 中称其为 "可用区(Availability Zones",这里我们也称其为 "区")。
它是广泛意义上的集群联邦特性的轻量级版本 (之前被称为 ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md))。
完整的集群联邦能够将多个分别运行在不同区或云供应商(或本地数据中心)的集群集中管理。
然而,很多用户只是希望通过将单一云供应商上的Kubernetes集群运行在多个区域,来提高集群的可用性,
这就是1.2版本中提供的对多区域的支持。
(之前被称为 "Ubernetes Lite")。
多区域的支持是有明确限制的: Kubernetes集群能够运行在多个区,但必须在同一个地域内 (云供应商也须一致)。
目前只有GCE和AWS自动支持 (尽管在其他云甚至裸机上,也很容易通过为节点和卷添加合适的标签来实现类似的支持)。
{{< toc >}}
## 功能
节点启动时,Kubelet自动为其添加区信息的标签。
在单一区域的集群中,Kubernetes 会自动将副本管理器或服务的pod分布到各节点上 (以减轻单实例故障的影响)。
在多区域的集群中,这种分布的行为扩展到了区域级别
(以减少区域故障对整体的影响)。 (通过 `SelectorSpreadPriority` 来实现)。
这种分发是尽力而为(best-effort)的,所以如果集群在各个区之间是异构的
(比如,各区间的节点数量不同、节点类型不同、pod的资源需求不同等)可能导致pod无法完全均匀地分布。
如果需要的话,用户可以使用同质的区(节点数量和节点类型相同)来减少区域之间分配不均匀的可能。
当卷被创建时, `PersistentVolumeLabel`准入控制器会自动为其添加区域的标签。
调度器 (通过 `VolumeZonePredicate` 断言) 会确申领该卷的pod被调度到该卷对应的区域,
因为卷是不支持跨区挂载的。
## 限制
对多区的支持有一些重要的限制:
* 我们假设不同的区域间在网络上离得很近,所以我们不做任何的区域感知路由。 特别是,通过服务的网络访问可能跨区域 (即使该服务后端pod的其中一些运行在与客户端相同的区域中),这可能导致额外的延迟和损耗。
* 卷的区域亲和性只对 `PersistentVolume`有效。 例如,如果你在pod的spec中直接指定一个EBS的卷,则不会生效。
* 集群不支持跨云平台或地域 (这些功能需要完整的集群联邦特性支持)。
* 尽管节点位于多区域,目前默认情况下 kube-up 创建的管理节点是单实例的。 所以尽管服务是高可用的,并且能够容忍跨区域的性能损耗,管理平面还是单区域的。 需要高可用的管理平面的用户可以按照 [高可用](/docs/admin/high-availability) 指导来操作。
* 目前StatefulSet的卷动态创建时的跨区域分配,与pod的亲和性/反亲和性不兼容。
* StatefulSet的名称包含破折号 ("-")时,可能影响到卷在区域间的均匀分布。
* 为deployment或pod指定多个PVC时,要求其StorageClass处于同一区域内,否则,相应的PV卷需要在一个区域中静态配置。 另一种方式是使用StatefulSet,这可以确保同一副本所挂载的卷位于同一区内。
## 演练
接下来我们将介绍如何同时在 GCE 和 AWS 上创建和使用多区域的集群。 为此,你需要创建一个完整的集群
(指定 `MULTIZONE=true`),然后再次执行 `kube-up`(指定 `KUBE_USE_EXISTING_MASTER=true`)来添加其他区域的节点。
### 创建集群
按正常方式创建集群,但是传入 MULTIZONE 来通知集群对多区域进行管理。 在 us-central1-a 区域创建节点。
GCE:
```shell
curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a NUM_NODES=3 bash
```
AWS:
```shell
curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash
```
该步骤按正常方式创建了集群,仍然运行在单个区域中。
`MULTIZONE=true` 已经开启了多区域的能力。
### 标记节点
查看节点,你可以发现节点上打了区域信息的标签。
节点位于 `us-central1-a` (GCE) 或者 `us-west-2a` (AWS)。 标签 `failure-domain.beta.kubernetes.io/region` 用于区分地域,
标签 `failure-domain.beta.kubernetes.io/zone` 用于区分区域。
```shell
> kubectl get nodes --show-labels
NAME STATUS AGE VERSION LABELS
kubernetes-master Ready,SchedulingDisabled 6m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
kubernetes-minion-87j9 Ready 6m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
kubernetes-minion-9vlv Ready 6m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
kubernetes-minion-a12q Ready 6m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
```
### 添加其它区中的节点
接下来我们复用已有的管理节点,添加运行于其它区域 (us-central1-b或us-west-2b)中的节点。
再次执行 kube-up 通过指定 `KUBE_USE_EXISTING_MASTER=true`
kube-up 不会创建新的管理节点,而是会复用之前创建的。
GCE:
```shell
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh
```
在 AWS 中我们还需要为新增的子网指定网络CIDR,还有管理节点的内部IP地址。
```shell
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
```
再次查看节点,3个新增的节点已经启动,并被标记为us-central1-b
```shell
> kubectl get nodes --show-labels
NAME STATUS AGE VERSION LABELS
kubernetes-master Ready,SchedulingDisabled 16m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
kubernetes-minion-281d Ready 2m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
kubernetes-minion-87j9 Ready 16m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
kubernetes-minion-9vlv Ready 16m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
kubernetes-minion-a12q Ready 17m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
kubernetes-minion-pp2f Ready 2m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
kubernetes-minion-wf8i Ready 2m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
```
### 卷的亲和性
使用动态创建卷的功能创建一个卷 (只有PV持久卷才支持区域亲和性):
```json
kubectl create -f - <<EOF
{
"kind": "PersistentVolumeClaim",
"apiVersion": "v1",
"metadata": {
"name": "claim1",
"annotations": {
"volume.alpha.kubernetes.io/storage-class": "foo"
}
},
"spec": {
"accessModes": [
"ReadWriteOnce"
],
"resources": {
"requests": {
"storage": "5Gi"
}
}
}
}
EOF
```
**注意:** Kubernetes 1.3以上的版本中可以将PVC分发到多个已配置的区域中,在1.2版本中, 动态卷只能创建在管理节点所在的区域内(即这里的 us-central1-a / us-west-2a);相关issue
([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
在1.3后续的版本中已解决。
现在我们验证一下 Kubernetes 自动为创建的PV打上了所在地域和区域的标签。
```shell
> kubectl get pv --show-labels
NAME CAPACITY ACCESSMODES STATUS CLAIM REASON AGE LABELS
pv-gce-mj4gm 5Gi RWO Bound default/claim1 46s failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a
```
现在我们将创建使用这些PVC的pod。
因为 GCE 的PD存储 / AWS 的EBS 卷 不支持跨区域挂载,
这意味着相应的pod只能创建在卷所在的区域中。
```yaml
kubectl create -f - <<EOF
kind: Pod
apiVersion: v1
metadata:
name: mypod
spec:
containers:
- name: myfrontend
image: nginx
volumeMounts:
- mountPath: "/var/www/html"
name: mypd
volumes:
- name: mypd
persistentVolumeClaim:
claimName: claim1
EOF
```
注意pod被自动创建在了卷所在的区域中,因为云供应商通常不支持卷的跨区域挂载(attach)。
```shell
> kubectl describe pod mypod | grep Node
Node: kubernetes-minion-9vlv/10.240.0.5
> kubectl get node kubernetes-minion-9vlv --show-labels
NAME STATUS AGE VERSION LABELS
kubernetes-minion-9vlv Ready 22m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
```
### Pod的跨区域分布
副本管理器或服务的pod被自动创建在了不同的区域。 首先,在第三个区域内启动节点:
GCE:
```shell
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-f NUM_NODES=3 kubernetes/cluster/kube-up.sh
```
AWS:
```shell
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
```
验证你现在在3个区域内拥有节点:
```shell
kubectl get nodes --show-labels
```
创建 guestbook-go 示例应用, 它包含一个副本数为3的RC,运行一个简单的网络应用:
```shell
find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl create -f {}
```
Pod应该分布在全部3个区域上:
```shell
> kubectl describe pod -l app=guestbook | grep Node
Node: kubernetes-minion-9vlv/10.240.0.5
Node: kubernetes-minion-281d/10.240.0.8
Node: kubernetes-minion-olsh/10.240.0.11
> kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels
NAME STATUS AGE VERSION LABELS
kubernetes-minion-9vlv Ready 34m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
kubernetes-minion-281d Ready 20m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
kubernetes-minion-olsh Ready 3m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
```
负载平衡器覆盖集群中的所有区域; guestbook-go 示例包含一个
负载均衡服务的例子:
```shell
> kubectl describe service guestbook | grep LoadBalancer.Ingress
LoadBalancer Ingress: 130.211.126.21
> ip=130.211.126.21
> curl -s http://${ip}:3000/env | grep HOSTNAME
"HOSTNAME": "guestbook-44sep",
> (for i in `seq 20`; do curl -s http://${ip}:3000/env | grep HOSTNAME; done) | sort | uniq
"HOSTNAME": "guestbook-44sep",
"HOSTNAME": "guestbook-hum5n",
"HOSTNAME": "guestbook-ppm40",
```
负载平衡器正确指向了所有的pod,即使它们位于不同的区域内。
### 停止集群
使用完成后,进行清理:
GCE:
```shell
KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh
```
AWS:
```shell
KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
```
-84
View File
@@ -1,84 +0,0 @@
---
approvers:
- Random-Liu
title: 节点设置校验
---
* TOC
{{< toc >}}
## 节点合规性测试
*节点合规性测试* 是一个容器化的测试框架,提供了针对节点的系统验证和功能测试。 该测试主要检测节点是否满足 Kubernetes 的最低要求,通过检测的节点有资格加入 Kubernetes 集群。
## 限制
在 Kubernetes 1.5版本中,节点合规性测试存在以下限制:
* 节点合规性测试只支持 Docker 作为容器运行时环境。
## 节点的前提条件
为运行节点合规性测试,节点必须满足与标准的 Kubernetes 节点同样的前提条件。最基本地, 节点应安装以下组件:
* 容器运行时 (Docker)
* Kubelet
## 运行节点合规性测试
执行以下步骤来运行节点合规性测试:
1. 因为测试框架会启动一个本地的 master 来测试 Kubelet
所以将 Kubelet 指向本机 `--api-servers="http://localhost:8080"。 还有一些其他 Kubelet 参数可能需要注意:
* `--pod-cidr` 如果使用 `kubenet`, 需要为 Kubelet 任意指定一个 CIDR 例如 `--pod-cidr=10.180.0.0/24`。
* `--cloud-provider` 如果使用 `--cloud-provider=gce`,需要移除这个参数来运行测试。
2. 执行以下命令来运行节点合规性测试:
```shell
# $CONFIG_DIR 是 Kubelet 的 manifest 文件路径。
# $LOG_DIR 是测试结果输出的路径。
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
k8s.gcr.io/node-test:0.2
```
## 针对其他硬件体系结构运行节点合规性测试
Kubernetes 也为其他硬件体系结构的系统提供了节点合规性测试的 Docker 镜像:
Arch | Image |
--------|:-----------------:|
amd64 | node-test-amd64 |
arm | node-test-arm |
arm64 | node-test-arm64 |
## 运行选定的测试
为运行指定的测试,用正则表达式来描述将要运行的测试,并重载 `FOCUS` 环境变量。
```shell
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
-e FOCUS=MirrorPod \ # 只运行MirrorPod测试
k8s.gcr.io/node-test:0.2
```
为跳过指定的测试,用正则表达式来描述将要跳过的测试,并重载 `SKIP` 环境变量。
```shell
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
-e SKIP=MirrorPod \ # 运行除MirrorPod外的所有测试
k8s.gcr.io/node-test:0.2
```
节点合规性测试是[节点端到端测试](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/e2e-node-tests.md)的一个容器化的版本。
默认情况下, 它会运行所有的合规性测试用例。
理论上,只要合理地配置容器和挂载所需的卷,就可以运行任何的节点端到端测试用例。 但是这里 **强烈建议只运行合规性测试**,因为运行非合规性测试需要很多复杂的配置。
## 注意事项
* 测试会在节点上遗留一些Docker镜像, 包括节点合规性测试本身的镜像,和功能测试相关的镜像。
* 测试会在节点上遗留一些死的容器。这些容器是在功能测试的过程中创建的。
-22
View File
@@ -1,22 +0,0 @@
---
approvers:
- thockin
title: Kubernetes OpenVSwitch GRE/VxLAN 网络
---
本文档介绍了如何使用OpenVSwitch,在跨nodes的pods之间设置网络。
隧道类型可以是GRE或者是VxLAN。如需在网络内执行大规模隔离时,最好使用VxLAN。
![OVS Networking](/images/docs/ovs-networking.png)
Kubernetes中Vagrant的设置如下:
docker网桥被brctl生成的Linux网桥(kbr0)所代替,kbr0是具有256个地址空间的子网。总的来说,node会得到10.244.x.0/24的子网,docker上配置使用的网桥会代替默认docker0的网桥。
另外,OVS网桥创建(obr0),并将其作为端口添加到kbr0的网桥中。所有OVS网桥通过GRE隧道连接所有的nodes。因此,每个node都有一个到其他nodes的出站GRE隧道。这个隧道没有必要是一个完整的网状物,但是越像网状结构越好。在网桥上开启STP(生成树)模式以防止环路的发生。
路由规则允许任何10.244.0.0/16通过与隧道相连的OVS网桥到达目标。
@@ -1,89 +0,0 @@
---
approvers:
- bprashanth
- davidopp
- lavalamp
- liggitt
title: 管理Service Accounts
---
*这是一篇针对service accounts(服务账户)的集群管理员指南。 它呈现了 [User Guide to Service Accounts](/docs/user-guide/service-accounts)中的信息。*
*对授权和用户账户的支持已在规划中,当前并不完备,为了更好地描述service accounts,有时这些不完善的特性也会被提及。*
## 用户账户与服务账户
Kubernetes 区分用户账户和服务账户的概念主要基于以下原因:
- 用户账户是针对人而言的。 服务账户是针对运行在pod中的进程而言的。
- 用户账户是全局性的。 其名称在集群各namespace中都是全局唯一的,未来的用户资源不会做namespace隔离,
服务账户是namespace隔离的。
- 通常情况下,集群的用户账户可能会从企业数据库进行同步,其创建需要特殊权限,并且涉及到复杂的业务流程。 服务账户创建的目的是为了更轻量,允许集群用户为了具体的任务创建服务账户 (即权限最小化原则)。
- 对人员和服务账户审计所考虑的因素可能不同。
- 针对复杂系统的配置可能包含系统组件相关的各种服务账户的定义。 因为服务账户可以定制化地创建,并且有namespace级别的名称,这种配置是很轻量的。
## 服务账户的自动化
三个独立组件协作完成服务账户相关的自动化:
- 服务账户准入控制器(Service account admission controller
- Token控制器(Token controller
- 服务账户控制器(Service account controller
### 服务账户准入控制器
对pod的改动通过一个被称为[Admission Controller](/docs/admin/admission-controllers)的插件来实现。它是apiserver的一部分。
当pod被创建或更新时,它会同步地修改pod。 当该插件处于激活状态(在大多数发行版中都是默认的),当pod被创建或更新时它会进行以下动作:
1. 如果该pod没有 `ServiceAccount` 设置,将其 `ServiceAccount` 设为 `default`
2. 保证pod所关联的 `ServiceAccount` 存在,否则拒绝该pod。
4. 如果pod不包含 `ImagePullSecrets`设置,那么 将 `ServiceAccount`中的`ImagePullSecrets` 信息添加到pod中。
5. 将一个包含用于API访问的token的 `volume` 添加到pod中。
6. 将挂载于 `/var/run/secrets/kubernetes.io/serviceaccount``volumeSource`添加到pod下的每个容器中。
### Token管理器
Token管理器是controller-manager的一部分。 以异步的形式工作:
- 检测服务账户的创建,并且创建相应的Secret以支持API访问。
- 检测服务账户的删除,并且删除所有相应的服务账户Token Secret。
- 检测Secret的增加,保证相应的服务账户存在,如有需要,为Secret增加token。
- 检测Secret的删除,如有需要,从相应的服务账户中移除引用。
你需要通过 `--service-account-private-key-file` 参数项传入一个服务账户私钥文件至Token管理器。 私钥用于为生成的服务账户token签名。
同样地,你需要通过 `--service-account-key-file` 参数将对应的公钥传入kube-apiserver。 公钥用于认证过程中的token校验。
#### 创建额外的 API tokens
控制器中有专门的循环来保证每个服务账户中都存在API token对应的Secret。 当需要为服务账户创建额外的API token时,创建一个类型为 `ServiceAccountToken` 的Secret,并在annotation中引用服务账户,控制器会生成token并更新:
secret.json:
```json
{
"kind": "Secret",
"apiVersion": "v1",
"metadata": {
"name": "mysecretname",
"annotations": {
"kubernetes.io/service-account.name": "myserviceaccount"
}
},
"type": "kubernetes.io/service-account-token"
}
```
```shell
kubectl create -f ./secret.json
kubectl describe secret mysecretname
```
#### 删除/失效 服务账户token
```shell
kubectl delete secret mysecretname
```
### 服务账户管理器
服务账户管理器管理各命名空间下的服务账户,并且保证每个活跃的命名空间下存在一个名为 "default" 的服务账户
@@ -1,248 +0,0 @@
title: 云控制器管理器的基本概念
## 云控制器管理器
云控制器管理器(CCM)这个概念创建的初衷是为了让特定的云服务供应商代码和Kubernetes核心相互独立演化。云控制器管理器与其他主要组件如Kubernetes控制器管理器,API服务器和调度程序同时运行。云控制器管理器也可以作为Kubernetes的插件启动,这种情况下,CCM运行在Kubernetes系统之上。
云控制器管理器基于插件机制设计,允许新的云服务供应商通过插件轻松地与Kubernetes集成。目前已经有在Kubernetes上加入新的云服务供应商计划,并为云服务供应商提供从原先的旧模式迁移到新CCM模式的方案。
本文讨论了云控制器管理器背后的概念,并提供了相关功能的详细信息。
下面这张图描述了没有云控制器管理器的Kubernetes集群架构:
![无云控制器管理器的 K8s 集群架构](/images/docs/pre-ccm-arch.png)
## 设计
在上图中,Kubernetes和云服务供应商通过几个不同的组件进行了集成,分别是:
* Kubelet
* Kubernetes 控制管理器
* Kubernetes API服务器
而CCM整合了前三个组件中的所有依赖于云的逻辑,用来创建与云的单点集成。新架构如下图所示:
![有云控制器管理器的 K8s 集群架构](/images/docs/post-ccm-arch.png)
## CCM的组件
CCM突破了Kubernetes控制器管理器(KCM)的一些功能,并将其作为一个独立的进程运行。具体而言,它打破了KCM中与云相关的控制器。KCM具有以下依赖于云的控制器引擎:
* 节点控制器
* 卷控制器
* 路由控制器
* 服务控制器
在1.8版本中,当前运行中的CCM从上面的列表中运行以下控制器:
* 节点控制器
* 路由控制器
* 服务控制器
另外,它运行另一个名为 PersistentVolumeLabels Controller 的控制器。这个控制器负责对在GCP和AWS云里创建的PersistentVolumes的域(Zone)和区(Region)标签进行设置。
**注意**:卷控制器被特意设计为CCM之外的一部分。由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象,因此决定了卷控制器不会被移动到CCM之中。
原本计划使用CCM来支持卷的目的是为了引入FlexVolume卷来支持可插拔卷。然而,官方正在计划使用更具备竞争力的CSI来取代FlexVolume卷。
考虑到这些正在进行中的变化,我们决定暂时停止当前工作直至CSI准备就绪。
云服务供应商工作组(wg-cloud-provider)正在开展相关工作,以实现通过CCM支持PersistentVolume的功能。详细信息请参见[kubernetes/kubernetes52371](https://github.com/kubernetes/kubernetes/pull/52371)。
## CCM功能
CCM从Kubernetes组件中继承了与云服务供应商相关的功能。本节基于被CCM继承其功能的组件展开描述。
### 1. Kubernetes 控制器管理器
CCM的大部分功能都来自KCM。 如上一节所述,CCM运行以下控制引擎:
* 节点控制器
* 路由控制器
* 服务控制器
* PersistentVolumeLabels控制器
#### 节点控制器
节点控制器负责通过从云服务供应商获得有关在集群中运行的节点的信息来初始化节点。节点控制器执行以下功能:
1.使用云特定域(Zone)/区(Region)标签初始化节点。
1.使用特定于云的实例详细信息初始化节点,例如类型和大小。
1.获取节点的网络地址和主机名。
1.如果节点无响应,检查该节点是否已从云中删除。如果该节点已从云中删除,则删除Kubernetes节点对象。
#### 路由控制器
路由控制器负责为云配置正确的路由,以便Kubernetes集群中不同节点上的容器可以相互通信。路由控制器仅适用于Google Compute Engine平台。
#### 服务控制器
服务控制器负责监听服务的创建、更新和删除事件。根据Kubernetes中各个服务的当前状态,它将配置云负载平衡器(如ELB或Google LB)以反映Kubernetes中的服务状态。此外,它还确保云负载均衡器的服务后端保持最新。
#### PersistentVolumeLabels 控制器
PersistentVolumeLabels控制器在AWS的EBS卷、GCE的PD卷创建时申请标签,这使得用户不再需要手动设置这些卷标签。
这些标签对于pod的调度工作是非常重要的,因为这些卷只能在它们所在的域(Zone)/区(Region)内工作,因此所有使用这些卷的pod都必须要在同一个域/区中才能保证进行调度正常进行。
PersistentVolumeLabels控制器是专门为CCM创建的; 也就是说,在CCM创建之前它是不存在的。这样做是为了将Kubernetes API服务器(它是一个许可控制器)中的PV标签逻辑移动到CCM。 它不在KCM上运行。
### 2. Kubelet
Node控制器包含kubelet中依赖于云的功能。在系统引入CCM组件之前,是由kubelet采用包含云特定信息的方式对节点进行初始化,如IP地址、区(Region)/域(Zone)标签和实例类型信息;引入CCM之后,这部分的初始化操作就从kubelet转移到了CCM中。
在引入CCM后的新的模型中,kubelet采用不包含云特定信息的方式初始化一个节点。但是,它会为新创建的节点添加一个污点,使得该节点不可被立即调度,直到CCM使用包含云的特定信息初始化节点后,才会删除该污点,使得该节点可被调度。
### 3. Kubernetes API服务器
PersistentVolumeLabels控制器将Kubernetes API服务器的依赖于云的功能移至CCM,如前面部分所述。
## 插件机制
云控制器管理器使用Go接口与外部对接从而实现功能扩展。具体来说,它使用了[这里](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go)定义的CloudProvider接口。
上面强调的四个共享控制器的实现,以及一些辅助设施(scaffolding)和共享的云服务供应商接口,将被保留在Kubernetes核心当中。但云服务供应商特有的实现将会建立在核心之外,并实现核心中定义的接口。
有关开发插件的更多信息,请参阅
[开发云控制器管理器](/docs/tasks/administrators-cluster/developing-cloud-controller-manager/)。
## 授权
本节分解了CCM对各种API对象的访问,以执行其操作。
### 节点控制器
节点控制器仅适用于节点对象。它需要完全访问权限来获取、列出、创建、更新、修补、监视和删除节点对象。
v1/Node:
- Get
- List
- Create
- Update
- Patch
- Watch
### 路由控制器
路由控制器监听节点对象的创建并配置合适的路由。它需要对节点对象的访问权限。
v1/Node:
- Get
### 服务控制器
服务控制器侦听服务对象创建、更新和删除事件,然后对这些服务的端点进行恰当的配置。
要访问服务,它需要罗列和监控权限。要更新服务,它需要修补和更新权限。
要为服务设置端点,需要访问创建、列表、获取、监视和更新。
v1/Service:
- List
- Get
- Watch
- Patch
- Update
### PersistentVolumeLabels 控制器
PersistentVolumeLabels控制器监听PersistentVolume(PV)创建事件并更新它们。该控制器需要访问列表、查看、获取和更新PV的权限。
v1/PersistentVolume:
- Get
- List
- Watch
- Update
### 其它
CCM核心的实现需要创建事件的权限,为了确保安全操作,需要创建ServiceAccounts的权限。
v1/Event:
- Create
- Patch
- Update
v1/ServiceAccount:
- Create
针对CCM的RBAC ClusterRole如下所示:
```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
```
## 供应商实施
以下云服务供应商为自己的云部署了CCM。
* [Digital Ocean]()
* [Oracle]()
* [Azure]()
* [GCE]()
* [AWS]()
## 群集管理
[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了配置和运行CCM的完整说明。
@@ -1,70 +0,0 @@
---
approvers:
- dchen1107
- roberthbailey
- liggitt
title: Master 节点通信
---
{{< toc >}}
## 概览
本文对 Master 节点(确切说是 apiserver)和 Kubernetes 集群之间的通信路径进行了分类。目的是为了让用户能够自定义他们的安装,对网络配置进行加固,使得集群能够在不可信的网络上(或者在一个云服务商完全公共的 IP 上)运行。
## Cluster -> Master
所有从集群到 master 的通信路径都终止于 apiserver(其它 master 组件没有被设计为可暴露远程服务)。在一个典型的部署中,apiserver 被配置为在一个安全的 HTTPS 端口(443)上监听远程连接并启用一种或多种形式的客户端[身份认证](/docs/admin/authentication/)机制。一种或多种客户端[身份认证](/docs/admin/authentication/)机制应该被启用,特别是在允许使用 [匿名请求](/docs/admin/authentication/#anonymous-requests) 或 [service account tokens](/docs/admin/authentication/#service-account-tokens) 的时候。
应该使用集群的公共根证书开通节点,如此它们就能够基于有效的客户端凭据安全的连接 apiserver。例如:在一个默认的 GCE 部署中,客户端凭据以客户端证书的形式提供给 kubelet。请查看 [kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) 获取如何自动提供 kubelet 客户端证书。
想要连接到 apiserver 的 Pods 可以使用一个 service account 安全的进行连接。这种情况下,当 Pods 被实例化时 Kubernetes 将自动的把公共根证书和一个有效的不记名令牌注入到 pod 里。`kubernetes` service (所有 namespaces 中)都配置了一个虚拟 IP 地址,用于转发(通过 kube-proxy)请求到 apiserver 的 HTTPS endpoint。
Master 组件通过非安全(没有加密或认证)端口和集群的 apiserver 通信。这个端口通常只在 master 节点的 localhost 接口暴露,这样,所有在相同机器上运行的 master 组件就能和集群的 apiserver 通信。一段时间以后,master 组件将变为使用带身份认证和权限验证的安全端口(查看[#13598](https://github.com/kubernetes/kubernetes/issues/13598))。
这样的结果使得从集群(在节点上运行的 nodes 和 pods)到 master 的缺省连接操作模式默认被保护,能够在不可信或公网中运行。
## Master -> Cluster
从 masterapiserver)到集群有两种主要的通信路径。第一种是从 apiserver 到集群中每个节点上运行的 kubelet 进程。第二种是从 apiserver 通过它的代理功能到任何 node、pod 或者 service。
### apiserver -> kubelet
从 apiserver 到 kubelet 的连接用于获取 pods 日志、连接(通过 kubectl)运行中的 pods,以及使用 kubele 的端口转发功能。这些连接终止于 kubelet 的 HTTPS endpoint。
默认的,apiserver 不会验证 kubelet 的服务证书,这会导致连接遭到中间人攻击,因而在不可信或公共网络上是不安全的。
为了对这个连接进行认证,请使用 `--kubelet-certificate-authority` 标记给 apiserver 提供一个根证书捆绑,用于 kubelet 的服务证书。
如果这样不可能,又要求避免在不可信的或公共的网络上进行连接,请在 apiserver 和 kubelet 之间使用 [SSH 隧道](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)。
最后,应该启用[Kubelet 用户认证和/或权限认证](/docs/admin/kubelet-authentication-authorization/)来保护 kubelet API。
### apiserver -> nodes, pods, and services
从 apiserver 到 node、pod或者service 的连接默认为纯 HTTP 方式,因此既没有认证,也没有加密。他们能够通过给API URL 中的 node、pod 或 service 名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。但他们即不会认证 HTTPS endpoint 提供的证书,也不会提供客户端证书。这样虽然连接是加密的,但它不会提供任何完整性保证。这些连接**目前还不能安全的**在不可信的或公共的网络上运行。
### SSH 隧道
[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/) 使用 SSH 隧道保护 Master -> Cluster 通信路径。在这种配置下,apiserver 发起一个到集群中每个节点的 SSH 隧道(连接到在 22 端口监听的 ssh 服务)并通过这个隧道传输所有到 kubelet、node、pod 或者 service 的流量。这个隧道保证流量不会在集群运行的私有 GCE 网络之外暴露。
@@ -1,233 +0,0 @@
---
approvers:
- caesarxuchao
- dchen1107
title: Nodes
redirect_from:
- "/docs/admin/node/"
- "/docs/admin/node.html"
- "/docs/concepts/nodes/node/"
- "/docs/concepts/nodes/node.html"
---
{{< toc >}}
## Node 是什么?
`Node` 是 Kubernetes 的工作节点,以前叫做 `minion`。取决于你的集群,Node 可以是一个虚拟机或者物理机器。每个 node 都有用于运行 [pods](/docs/user-guide/pods) 的必要服务,并由 master 组件管理。Node 上的服务包括 Docker、kubelet 和 kube-proxy。请查阅架构设计文档中 [The Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) 一节获取更多细节。
## Node 状态
一个 node 的状态包含以下信息:
* [地址](#地址)
* ~~[阶段](#阶段)~~ **已废弃**
* [条件](#条件)
* [容量](#容量)
* [信息](#信息)
下面对每个章节进行详细描述。
### 地址
这些字段组合的用法取决于你的云服务商或者裸机配置。
* HostNameHostName 和 node 内核报告的相同。可以通过 kubelet 的 `--hostname-override` 参数覆盖。
* ExternalIP:通常是可以外部路由的 node IP 地址(从集群外可访问)。
* InternalIP:通常是仅可在集群内部路由的 node IP 地址。
### 阶段
一废弃:node 阶段已经不再使用。
### 条件
`conditions` 字段描述了所有 `Running` nodes 的状态。
| Node 条件 | 描述 |
| ---------------- | ---------------------------------------- |
| `OutOfDisk` | `True` 表示 node 的空闲空间不足以用于添加新 pods, 否则为 `False` |
| `Ready` | `True` 表示 node 是健康的并已经准备好接受 pods;`False` 表示 node 不健康而且不能接受 pods;`Unknown` 表示 node 控制器在最近 40 秒内没有收到 node 的消息 |
| `MemoryPressure` | `True` 表示 node 不存在内存压力 -- 即 node 内存用量低, 否则为 `False` |
| `DiskPressure` | `True` 表示 node 不存在磁盘压力 -- 即磁盘用量低, 否则为 `False` |
Node 条件使用一个 JSON 对象表示。例如,下面的响应描述了一个健康的 node。
```json
"conditions": [
{
"kind": "Ready",
"status": "True"
}
]
```
如果 Ready 条件处于状态 "Unknown" 或者 "False" 的时间超过了 `pod-eviction-timeout`(一个传递给 [kube-controller-manager](/docs/admin/kube-controller-manager/) 的参数),node 上的所有 Pods 都会被 Node 控制器计划删除。默认的删除超时时长为**5分钟**。某些情况下,当 node 不可访问时,apiserver 不能和其上的 kubelet 通信。删除 pods 的决定不能传达给 kubelet,直到它重新建立和 apiserver 的连接为止。与此同时,被计划删除的 pods 可能会继续在分区 node 上运行。
在 1.5 版本之前的 Kubernetes 里,node 控制器会将不能访问的 pods 从 apiserver 中[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)。但在 1.5 或更高的版本里,在node 控制器确认这些 pods 已经在集群里停运行前不会强制删除它们。你可以看到这些处于 "Terminating" 或者 "Unknown" 状态的 pods 可能在无法访问的 node 上运行。为了防止 kubernetes 不能从底层基础设施中推断出一个 node 是否已经永久的离开了集群,集群管理员可能需要手动删除这个 node 对象。从 Kubernetes 删除 node 对象将导致 apiserver 删除 node 上所有运行的 Pod 对象并释放它们的名字。
### 容量
描述 node 上的可用资源:CPU、内存和可以调度到 node 上的 pods 的最大数量。
### 信息
关于 node 的通用信息,例如内核版本、Kubernetes 版本(kubelet 和 kube-proxy 版本)、Docker 版本 (如果使用了)和 OS 名。这些信息由 Kubelet 从 node 搜集而来。
## 管理
与 [pods](/docs/user-guide/pods) 和 [services](/docs/user-guide/services) 不同,node 并不是在 Kubernetes 内部创建的:它是被外部的云服务商创建,例如 Google Compute Engine 或者你的集群中的物理或者虚拟机。这意味着当 Kubernetes 创建一个 node 时,它其实仅仅创建了一个对象来代表这个 node。创建以后,Kubernetes 将检查这个 node 是否可用。例如,如果你尝试使用如下内容创建一个 node:
```json
{
"kind": "Node",
"apiVersion": "v1",
"metadata": {
"name": "10.240.79.157",
"labels": {
"name": "my-first-k8s-node"
}
}
}
```
Kubernetes 会在内部创一个 node 对象(象征 node),并基于 `metadata.name` 字段(我们假设 `metadata.name` 能够被解析)通过健康检查来验证 node。如果 node 可用,意即所有必要服务都已运行,它就符合了运行一个 pod 的条件;否则它将被所有的集群动作忽略直到变为可用。请注意,Kubernetes 将保存不可用 node 的对象,除非它被客户端显式的删除。Kubernetes 将持续检查 node 是否变的可用。
当前,有3个组件同 Kubernetes node 接口交互:node 控制器、kubelet 和 kubectl。
### Node 控制器
Node 控制器是一个 Kubernetes master 组件,管理 nodes 的方方面面。
Node 控制器在 node 的生命周期中扮演了多个角色。第一个是当 node 注册时为它分配一个 CIDR block(如果打开了 CIDR 分配)。
第二个是使用云服务商提供了可用节点列表保持 node 控制器内部的 nodes 列表更新。如果在云环境下运行,任何时候当一个 node 不健康时 node 控制器将询问云服务 node 的虚拟机是否可用。如果不可用,node 控制器会将这个 node 从它的 nodes 列表删除。
第三个是监控 nodes 的健康情况。Node 控制器负责在 node 不能访问时(也即是 node 控制器因为某些原因没有收到心跳,例如 node 宕机)将它的 NodeStatus 的 NodeReady 状态更新为 ConditionUnknown。后续如果 node 持续不可访问,Node 控制器将删除 node 上的所有 pods(使用优雅终止)。(默认情况下 40s 开始报告 ConditionUnknown,在那之后 5m 开始删除 pods。)Node 控制器每隔 `--node-monitor-period` 秒检查每个 node 的状态。
在 Kubernetes 1.4 中我们更新了 node 控制器逻辑以更好的处理大批量 nodes 访问 master 出问题的情况(例如 master 的网络出了问题)。从 1.4 开始,node 控制器在决定删除 pod 之前会检查集群中所有 nodes 的状态。
大部分情况下, node 控制器把删除频率限制在每秒 `--node-eviction-rate` 个(默认为 0.1)。这表示它在 10 秒钟内不会从超过一个 node 上删除 pods。
当一个 availability zone 中的 node 变为不健康时,它的删除行为将发生改变。Node 控制器会同时检查 zone 中不健康(NodeReady 状态为 ConditionUnknown 或 ConditionFalse)的 nodes 的百分比。如果不健康 nodes 的部分超过 `--unhealthy-zone-threshold` (默认为 0.55),删除速率将会减小:如果集群较小(意即小于等于 `--large-cluster-size-threshold` 个 nodes - 默认为50),删除将会停止,否则删除速率将降为每秒 `--secondary-node-eviction-rate` 个(默认为 0.01)。在单个 availability zone 实施这些策略的原因是当一个 availability zone 可能从 master 分区时其它的仍然保持连接。如果你的集群没有跨越云服务商的多个 availability zones,那就只有一个 availability zone(整个集群)。
在多个 availability zones 分布你的 nodes 的一个关键原因是当整个 zone 故障时,工作负载可以转移到健康的 zones。因此,如果一个 zone 中的所有 nodes 都不健康时,node 控制器会以正常的速率 `--node-eviction-rate` 删除。在所有的 zones 都不健康(也即集群中没有健康 node)的极端情况下,node 控制器将假设 master 的连接出了某些问题,它将停止所有删除动作直到一些连接恢复。
从 Kubernetes 1.6 开始,NodeController 还负责删除运行在拥有 `NoExecute` taints 的 nodes 上的 pods,如果这些 pods 没有 tolerate 这些 taints。此外,作为一个默认禁用的 alpha 特性,NodeController 还负责根据 node 故障(例如 node 不可访问或没有 ready)添加 taints。请查看 [这个文档](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)了解关于 `NoExecute` taints 和这个 alpha 特性。
### Nodes 自注册
当 kubelet 标志 `--register-node` 为 true (默认)时,它会尝试向 API 服务注册自己。这是首选模式,被绝大多数发行版选用。
对于自注册模式,kubelet 使用下列参数启动:
- `--api-servers` - apiservers 地址。
- `--kubeconfig` - 用于向 apiserver 验证自己的凭据路径。
- `--cloud-provider` - 如何从云服务商读取关于自己的元数据。
- `--register-node` - 自动向 API 服务注册。
- `--register-with-taints` - 使用 taints 列表(逗号分隔的 `<key>=<value>:<effect>`)注册 node。当 `register-node` 为 false 时无效。
- `--node-ip` - node IP 地址。
- `--node-labels` - 向集群注册时给 node 添加的 labels。
- `--node-status-update-frequency` - 指定 kubelet 向 master 发送状态的频率。
目前,任何 kubelet 都被授权可以创建/修改任意 node 资源,但通常只对自己的进行创建/修改。(未来我们计划只允许一个 kubelet 修改它自己 node 的资源。)
#### 手动 Node 管理
集群管理员可以创建及修改 node 对象。
如果管理员希望手动创建 node 对象,请设置 kubelet 标记 `--register-node=false`
管理员可以修改 node 资源(忽略 `--register-node` 设置)。修改包括在 node 上设置 labels及标记它为不可调度。
Nodes 上的 labels 可以和 pods 的 node selectors 一起使用来控制调度,例如限制一个 pod 只能在一个符合要求的 nodes 子集上运行。
标记一个 node 为不可调度的将防止新建 pods 调度到那个 node 之上,但不会影响任何已经在它之上的 pods。这是重启 node 等操作之前的一个有用的准备步骤。例如,标记一个 node 为不可调度的,执行以下命令:
```shell
kubectl cordon $NODENAME
```
请注意,被 daemonSet 控制器创建的 pods 将忽略 Kubernetes 调度器,且不会遵照 node 上不可调度的属性。这个假设基于守护程序属于节点机器,即使在准备重启而隔离应用的时候。
### Node 容量
Node 的容量(cpu 数量和内存容量)是 node 对象的一部分。通常情况下,在创建 node 对象时,它们会注册自己并报告自己的容量。如果你正在执行[手动 node 管理](#manual-node-administration),那么你需要在添加 node 时手动设置 node 容量。
Kubernetes 调度器保证一个 node 上有足够的资源供其上的所有 pods 使用。它会检查 node 上所有容器要求的总和不会超过 node 的容量。这包括所有 kubelet 启动的容器,但不包含 Docker 启动的容器和不在容器中的进程。
如果希望显式的为非 pod 进程预留资源,你可以创建一个占位 pod。使用如下模板:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: resource-reserver
spec:
containers:
- name: sleep-forever
image: k8s.gcr.io/pause:0.8.0
resources:
requests:
cpu: 100m
memory: 100Mi
```
设置 `cpu``memory` 值为你希望预留的资源量。将文件放在清单文件夹中(kubelet 的 `--config=DIR` 标志)。当你希望预留资源时,在每个 kubelet 上都这样执行。
## API 对象
Node 是 Kubernetes REST API 的顶级资源。更多关于 API 对象的细节可以在这里找到: [Node API
object](/docs/api-reference/{{< param "version" >}}/#node-v1-core).``
@@ -1,45 +0,0 @@
---
title: 安装扩展(Addons
---
## 概览
Add-ons 扩展了 Kubernetes 的功能。
本文列举了一些可用的 add-ons 以及到它们各自安装说明的链接。
每个 add-ons 按字母顺序排序 - 顺序不代表任何优先地位。
## 网络和网络策略
* [Calico](http://docs.projectcalico.org/latest/getting-started/kubernetes/installation/hosted/) 是一个安全的 L3 网络和网络策略提供者。
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) 结合 Flannel 和 Calico, 提供网络和网络策略。
* [Cilium](https://github.com/cilium/cilium) 是一个 L3 网络和网络策略插件, 能够透明的实施 HTTP/API/L7 策略。 同时支持路由(routing)和叠加/封装( overlay/encapsulation)模式。
* [Contiv](http://contiv.github.io) 为多种用例提供可配置网络(使用 BGP 的原生 L3,使用 vxlan 的 overlay,经典 L2 和 Cisco-SDN/ACI)和丰富的策略框架。Contiv 项目完全[开源](http://github.com/contiv)。[安装工具](http://github.com/contiv/install)同时提供基于和不基于 kubeadm 的安装选项。
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) 是一个可以用于 Kubernetes 的 overlay 网络提供者。
* [Romana](http://romana.io) 是一个 pod 网络的层 3 解决方案,并且支持 [NetworkPolicy API](/docs/concepts/services-networking/network-policies/)。Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) 提供了在网络分组两端参与工作的网络和网络策略,并且不需要额外的数据库。
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 使 Kubernetes 无缝连接到一种 CNI 插件,例如:Flannel、Calico、Canal、Romana 或者 Weave。
## 可视化管理
* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) 是一个 Kubernetes 的 web 控制台界面。
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) 是一个图形化工具,用于查看你的 containers、 pods、services等。 请和一个 [Weave Cloud account](https://cloud.weave.works/) 一起使用,或者自己运行 UI。
## 遗留 Add-ons
还有一些其它 add-ons 归档在已废弃的 [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) 路径中。
维护完善的 add-ons 应该被链接到这里。欢迎提出 PRs!
@@ -1,247 +0,0 @@
---
cn-approvers:
- lichuqiang
title: 证书
---
{{< toc >}}
## 创建证书
当使用客户端证书进行认证时,用户可以使用现有部署脚本,或者通过 `easyrsa``openssl`
`cfssl` 手动生成证书。
### 使用现有部署脚本
**现有部署脚本** 位于
`cluster/saltbase/salt/generate-cert/make-ca-cert.sh`
执行该脚本时需传入两个参数。 第一个参数为 API 服务器的 IP 地址,第二个参数为对象的候补名称列表,
形如 `IP:<ip地址> 或 DNS:<dns名称>`
脚本生成三个文件: `ca.crt``server.crt``server.key`
最后,将以下参数加入到 API 服务器的启动参数中:
```
--client-ca-file=/srv/kubernetes/ca.crt
--tls-cert-file=/srv/kubernetes/server.crt
--tls-private-key-file=/srv/kubernetes/server.key
```
### easyrsa
使用 **easyrsa** 能够手动地为集群生成证书。
1. 下载、解压并初始化 easyrsa3 的补丁版本。
curl -L -O https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
tar xzf easy-rsa.tar.gz
cd easy-rsa-master/easyrsa3
./easyrsa init-pki
1. 生成 CA(通过 `--batch` 参数设置自动模式。 通过 `--req-cn` 设置默认使用的 CN
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
1. 生成服务器证书和密钥。
参数 `--subject-alt-name` 设置了访问 API 服务器时可能使用的 IP 和 DNS 名称。 `MASTER_CLUSTER_IP`
通常为 `--service-cluster-ip-range` 参数中指定的服务 CIDR 的 首个 IP 地址,`--service-cluster-ip-range`同时用于
API 服务器和控制器管理器组件。 `--days` 参数用于设置证书的有效期限。
下面的示例还假设用户使用 `cluster.local` 作为默认的 DNS 域名。
./easyrsa --subject-alt-name="IP:${MASTER_IP}"\
"IP:${MASTER_CLUSTER_IP},"\
"DNS:kubernetes,"\
"DNS:kubernetes.default,"\
"DNS:kubernetes.default.svc,"\
"DNS:kubernetes.default.svc.cluster,"\
"DNS:kubernetes.default.svc.cluster.local" \
--days=10000 \
build-server-full server nopass
1. 拷贝 `pki/ca.crt``pki/issued/server.crt``pki/private/server.key` 至您的目录。
1. 填充并在 API 服务器的启动参数中添加以下参数:
--client-ca-file=/yourdirectory/ca.crt
--tls-cert-file=/yourdirectory/server.crt
--tls-private-key-file=/yourdirectory/server.key
### openssl
使用 **openssl** 能够手动地为集群生成证书。
1. 生成密钥位数为 2048 的 ca.key
openssl genrsa -out ca.key 2048
1. 依据 ca.key 生成 ca.crt (使用 -days 参数来设置证书有效时间):
openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
1. 生成密钥位数为 2048 的 server.key
openssl genrsa -out server.key 2048
1. 创建用于生成证书签名请求(CSR)的配置文件。
确保在将其保存至文件(如`csr.conf`)之前将尖括号标记的值(如`<MASTER_IP>`
替换为你想使用的真实值。 注意:`MASTER_CLUSTER_IP` 是前面小节中描述的 API 服务器的服务集群 IP
(service cluster IP)。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
[ dn ]
C = <country>
ST = <state>
L = <city>
O = <organization>
OU = <organization unit>
CN = <MASTER_IP>
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster
DNS.5 = kubernetes.default.svc.cluster.local
IP.1 = <MASTER_IP>
IP.2 = <MASTER_CLUSTER_IP>
[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectAltName=@alt_names
1. 基于配置文件生成证书签名请求:
openssl req -new -key server.key -out server.csr -config csr.conf
1. 使用 ca.key、ca.crt 和 server.csr 生成服务器证书:
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out server.crt -days 10000 \
-extensions v3_ext -extfile csr.conf
1. 查看证书:
openssl x509 -noout -text -in ./server.crt
最后,添加同样的参数到 API 服务器的启动参数中。
### cfssl
**cfssl** 是另一种用来生成证书的工具。
1. 按如下所示的方式下载、解压并准备命令行工具。
注意:你可能需要基于硬件架构和你所使用的 cfssl 版本对示例命令进行修改。
curl -LO https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o cfssl
chmod +x cfssl
curl -LO https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson
chmod +x cfssljson
curl -LO https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo
chmod +x cfssl-certinfo
1. 创建目录来存放物料,并初始化 cfssl:
mkdir cert
cd cert
../cfssl print-defaults config > config.json
../cfssl print-defaults csr > csr.json
1. 创建用来生成 CA 文件的 JSON 配置文件,例如 `ca-config.json`
{
"signing": {
"default": {
"expiry": "8760h"
},
"profiles": {
"kubernetes": {
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth",
],
"expiry": "8760h"
}
}
}
}
1. 创建用来生成 CA 证书签名请求(CSR)的 JSON 配置文件,例如 `ca-csr.json`
确保将尖括号标记的值替换为你想使用的真实值。
{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names":[{
"C": "<country>",
"ST": "<state>",
"L": "<city>",
"O": "<organization>",
"OU": "<organization unit>",
}]
}
1. 生成 CA 密钥(`ca-key.pem`)和证书(`ca.pem`):
../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
1. 按如下所示的方式创建用来为 API 服务器生成密钥和证书的 JSON 配置文件。
确保将尖括号标记的值替换为你想使用的真实值。 `MASTER_CLUSTER_IP` 是前面小节中描述的
API 服务器的服务集群 IP。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。
{
"CN": "kubernetes",
"hosts": [
"127.0.0.1",
"<MASTER_IP>",
"<MASTER_CLUSTER_IP>",
"kubernetes",
"kubernetes.default",
"kubernetes.default.svc",
"kubernetes.default.svc.cluster",
"kubernetes.default.svc.cluster.local"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [{
"C": "<country>",
"ST": "<state>",
"L": "<city>",
"O": "<organization>",
"OU": "<organization unit>"
}]
}
1. 为 API 服务器生成密钥和证书,生成的秘钥和证书分别默认保存在文件 `server-key.pem`
`server.pem` 中:
../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
--config=ca-config.json -profile=kubernetes \
server-csr.json | ../cfssljson -bare server
## 分发自签名 CA 证书
客户端节点可能拒绝承认自签名 CA 证书有效。
对于非生产环境的部署,或运行在企业防火墙后的部署,用户可以向所有客户端分发自签名 CA 证书,
并刷新本地的有效证书列表。
在每个客户端上执行以下操作:
```bash
$ sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....
done.
```
## 证书 API
您可以按照[这里](/docs/tasks/tls/managing-tls-in-a-cluster)记录的方式,
使用 `certificates.k8s.io` API 来准备 x509 证书,用于认证。
@@ -1,109 +0,0 @@
---
title: 云供应商
content_template: templates/concept
---
{{% capture overview %}}
本文介绍了如何管理运行在特定云供应商上的 Kubernetes 集群。
{{% /capture %}}
{{% capture body %}}
# AWS
本节介绍在 Amazon Web Services 上运行 Kubernetes 时可以使用的所有配置。
## 负载均衡器
用户可以通过配置注解(annotations)来设置 [外部负载均衡器](/docs/tasks/access-application-cluster/create-external-load-balancer/),以在 AWS 中使用特定功能,如下所示:
```yaml
apiVersion: v1
kind: Service
metadata:
name: example
namespace: kube-system
labels:
run: example
annotations:
service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #replace this value
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
spec:
type: LoadBalancer
ports:
- port: 443
targetPort: 5556
protocol: TCP
selector:
app: example
```
可以使用 _注解_ 将不同的设置应用于 AWS 中的负载平衡器服务。 下面描述了 AWS ELB 所支持的注解:
* `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`:用于指定访问日志的间隔。
* `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`:用于在服务中启用或禁用日志访问。
* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`:用于指定访问日志的 S3 桶名称。
* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`:用于指定访问日志的 S3 桶前缀。
* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`:用于在服务中指定一个逗号分隔的键值对列表,它将作为附加标签被记录在 ELB 中。 例如: `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`
* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`:用于在服务中指定监听器后端(pod)所使用的协议。 如果指定 `http` (默认) 或 `https`, 将创建一个终止连接和解析头的 HTTPS 监听器。 如果设置为 `ssl``tcp`, 将会使用 “原生的” SSL 监听器。 如果设置为 `http` 且不使用 `aws-load-balancer-ssl-cert`,将使用 HTTP 监听器。
* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`:用于在服务中请求安全监听器,其值为合法的证书 ARNAmazon Resource Name)。 更多内容,请参考 [ELB 监听器配置](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)。 证书 ARN 是 IAM(身份和访问管理) 或 CM(证书管理)类型的 ARN,例如 `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`
* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`:用于在服务中启用或禁用连接耗尽(connection draining)。
* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`:用于在服务中指定连接耗尽超时时间。
* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`:用于在服务中指定空闲连接超时时间。
* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`:用于在服务中启用或禁用跨区域负载平衡。
* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`:用于在服务中指定要添加到创建的 ELB 中的其他安全组。
* `service.beta.kubernetes.io/aws-load-balancer-internal`:用于在服务中表明需要内部 ELB。
* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`:用于在 ELB 上启用代理协议。 当前仅接受 `*` 值,也就是在所有 ELB 后端启用代理协议。 将来可能进行调整,只允许特定的后端设置代理协议。
* `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`:用于在服务中指定一个逗号分隔的端口列表,这些端口会使用 SSL/HTTPS 监听器。 默认为 `*`(全部)
AWS 相关的注解信息取自 [aws.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/aws/aws.go) 文件的注释。
# OpenStack
本节介绍了使用 OpenStack 运行 Kubernetes 时所有可用的配置。
## cloud.conf
Kubernetes 知道如何通过文件 cloud.conf 与 OpenStack 进行交互。 该文件会为 Kubernetes 提供证书和 OpenStack 认证端点的区位信息。
用户可以通过在其中指定以下信息来创建 cloud.conf 文件。
### 最小配置
这是一个最小配置的例子,它涉及最常用的值:
```yaml
[Global]
username=user
password=pass
auth-url=https://<keystone_ip>/identity/v3
tenant-id=c869168a828847f39f7f06edd7305637
domain-id=2a73b8f597c04551a0fdc8e95544be8a
[LoadBalancer]
subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a
```
#### 全局配置
* `username`:指 keystone 中设置的一个合法用户的用户名。
* `password`:指 keystone 中设置的一个合法用户的密码。
* `auth-url`:用于认证的 keystone API 的 URL 。 在 OpenStack 控制面板上,可以在 “访问和安全(Access and Security> api 访问(API Access> 凭证(Credentials)” 路径下找到它。
* `tenant-id`:用于指定要创建资源的项目 ID。
* `domain-id`:用于指定用户所属的域(domain)ID。
#### 负载均衡器
* `subnet-id`:用于指定要创建的负载均衡器所在的子网 ID。 可以在 “Network > Networks” 路径下找到它。 点击相应的网络获取其子网。
### 可选配置
#### 块存储
Kubernetes 利用 OpenStack 服务目录对它知道如何使用的服务进行定位,包括 Cinder 块存储服务。 然而,云供应商的配置中包含一个附加选项,可以影响块存储 API 的使用方式:
* `bs-version`:指所使用的块存储 API 版本。 其合法值为
`v1``v2``v3``auto``auto` 为默认值,将使用底层 Openstack 所支持的块存储 API 的最新版本。
如果在 OpenStack 上部署 Kubernetes <= 1.8 的版本,同时使用路径而不是端口来区分端点(endpoints),那么可能需要显式设置 `bs-version` 参数。 基于路径的端点形如 `http://foo.bar/volume` ,而基于端口的的端点形如
`http://foo.bar:xxx`
在使用基于路径的端点,并且 Kubernetes 使用较旧的自动检索逻辑的环境中,尝试卷卸载(detachment)会返回 `BS API version autodetection failed.` 错误。 为了解决这个问题,可以通过添加以下内容到云供应商配置中,来强制使用 Cinder API V2 版本。
```yaml
[BlockStorage]
bs-version=v2
```
{{% /capture %}}
@@ -1,87 +0,0 @@
---
approvers:
- davidopp
- lavalamp
title: 集群管理概述
content_template: templates/concept
---
{{% capture overview %}}
集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。我们假设你对 [用户指南](/docs/user-guide/)中的概念有一些熟悉。
{{% /capture %}}
{{% capture body %}}
## 规划集群
查阅 [选择正确解决方案](/docs/setup/pick-right-solution/) 中的指导,获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版*。
在选择一个指南前,有一些因素需要考虑:
- 你是打算在你的电脑上尝试 Kubernetes,还是要构建一个高可用的多节点集群?请选择最适合你需求的发行版。
- **如果你正在设计一个高可用集群**,请了解[在多个 zones 中配置集群](/docs/admin/multi-cluster)。
- 你的集群是在**本地**还是**云(IaaS**上?Kubernetes 不能直接支持混合集群。作为代替,你可以建立多个集群。
- **如果你在本地配置 Kubernetes**,需要考虑哪种[网络模型](/docs/admin/networking)最适合。一种自定义网络的选项是 [*OpenVSwitch GRE/VxLAN 网络*](/docs/admin/ovs-networking/),它使用 OpenVSwitch 在跨 Kubernetes 节点的 pods 之间建立起网络。
- 你的 Kubernetes 在 **裸金属硬件** 还是 **虚拟机(VMs)**上运行?
- 你**只想运行一个集群**,还是打算**活动开发 Kubernetes 项目代码**?如果是后者,请选择一个活动开发的发行版。某些发行版只提供二进制发布版,但提供更多的选择。
- 让你自己熟悉运行一个集群所需的[组件](/docs/admin/cluster-components) 。
请注意:不是所有的发行版都被积极维护着。请选择测试过最近版本的 Kubernetes 的发行版。
如果你正在使用和 Salt 有关的指南,请查阅 [使用 Salt 配置 Kubernetes](/docs/admin/salt)。
## 管理集群
[管理集群](/docs/concepts/cluster-administration/cluster-management/)叙述了和集群生命周期相关的几个主题:创建一个新集群、升级集群的 master 和 worker 节点、执行节点维护(例如内核升级)以及升级活动集群的 Kubernetes API 版本。
## 保护集群
* [Kubernetes 容器环境](/docs/concepts/containers/container-environment-variables/) 描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
* [控制到 Kubernetes API 的访问](/docs/admin/accessing-the-api) 描述了如何为用户和 service accounts 建立权限许可.
* [用户认证](/docs/admin/authentication) 阐述了 Kubernetes 中的认证功能,包括许多认证选项。
* [授权](/docs/admin/authorization)从认证中分离出来,用于控制如何处理 HTTP 请求。
* [使用 Admission Controllers](/docs/admin/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。
* [在 Kubernetes Cluster 中使用 Sysctls](/docs/concepts/cluster-administration/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。
* [审计](/docs/tasks/debug-application-cluster/audit/) 描述了如何与 Kubernetes 的审计日志交互。
### 保护 kubelet
* [Master 节点通信](/docs/concepts/cluster-administration/master-node-communication/)
* [TLS 引导](/docs/admin/kubelet-tls-bootstrapping/)
* [Kubelet 认证/授权](/docs/admin/kubelet-authentication-authorization/)
## 可选集群服务
* [DNS 与 SkyDNS 集成](/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个Kubernetes service。
* [记录和监控集群活动](/docs/concepts/cluster-administration/logging/) 阐述了Kubernetes 的日志如何工作以及怎样实现。
{{% /capture %}}
@@ -1,97 +0,0 @@
---
approvers:
title: 设备插件
description: 使用 Kubernetes 设备插件框架来为 GPUs、 NICs、 FPGAs、 InfiniBand 和其他类似的需要供应商特别设置的资源开发插件。
content_template: templates/concept
---
{{< feature-state state="alpha" >}}
{{% capture overview %}}
从1.8版本开始,Kubernetes 提供了一套
[设备插件框架](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)
使得供应商能够在不改动 Kubernetes 核心代码的情况下,向 kubelet 发布它们的资源。
供应商可以实现一个手动或以 DaemonSet 形式部署的插件,而不是编写自定义的 Kubernetes 代码。
插件的目标设备包括 GPUs、 高性能 NICs、 FPGAs、 InfiniBand
和其他类似的可能需要供应商特定的初始化和设置的计算资源。
{{% /capture %}}
{{% capture body %}}
## 设备插件注册
设备插件功能通过 `DevicePlugins` 功能入口控制, 该功能默认是禁用的。
当设备插件功能被启用时,kubelet 会对外提供一个 `Registration` gRPC 服务:
```gRPC
service Registration {
rpc Register(RegisterRequest) returns (Empty) {}
}
```
设备插件通过该 gRPC 服务将自身注册到 kubelet 。
注册过程中,设备插件需要发送:
* 它的 Unix 套接字名称。
* 所基于的设备插件 API 版本。
* 希望发布的 `ResourceName` 。 这里的 `ResourceName` 需要符合
[扩展资源命名方案](https://github.com/kubernetes/kubernetes/pull/48922)
形如 `vendor-domain/resource`
例如,Nvidia GPU 资源被发布为 `nvidia.com/gpu`
注册成功后,设备插件将其管理的设备列表发送至 kubelet ,然后 kubelet 负责将这些资源作为 kubelet 节点状态更新的一部分,通知 apiserver 。
例如, 设备插件注册 `vendor-domain/foo` 到 kubelet
并上报了节点上的两个健康的设备后,节点状态将更新, 发布2个 `vendor-domain/foo`
然后,开发者可以在 [容器](/docs/api-reference/{{< param "version" >}}/#container-v1-core)
规格中通过使用与
[不透明整数型资源](/docs/tasks/configure-pod-container/opaque-integer-resource/)
中同样的流程来请求使用设备。
在1.8版本中, 扩展资源仅支持整型的资源,且容器规格中声明的 `limit``request` 必须相等。
## 设备插件实现
设备插件的工作流程一般包括以下步骤:
* 初始化。 在这个阶段,设备插件执行供应商特定的初始化和设置,以确保设备处于就绪状态。
* 插件通过主机路径 `/var/lib/kubelet/device-plugins/` 下的一个 Unix 套接字启动 gRPC 服务,该服务实现了以下接口:
```gRPC
service DevicePlugin {
// ListAndWatch returns a stream of List of Devices
// Whenever a Device state change or a Device disappears, ListAndWatch
// returns the new list
rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
// Allocate is called during container creation so that the Device
// Plugin can run device specific operations and instruct Kubelet
// of the steps to make the Device available in the container
rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
}
```
* 插件通过主机路径 `/var/lib/kubelet/device-plugins/kubelet.sock` 下的 Unix 套接字将自身注册到 kubelet 。
* 注册成功之后,设备插件以服务模式运行,其间持续监测设备健康状态,并在任何设备状态变化时上报到 kubelet 。
插件也负责服务 `Allocate` gRPC 请求。 在 `Allocate` 过程中,插件可能会做设备特定的准备动作; 如 GPU 清理 或 QRNG 初始化。
如操作成功,设备插件会返回一个 `AllocateResponse` ,它包含了用于访问分配的设备的容器运行时配置信息。 kubelet 将该信息传递到容器运行时。
我们期望设备插件能够监测到 kubelet 重启,并将自身重新注册到新的 kubelet 实例中。 在1.8版本中,新的 kubelet 实例启动时,会清理当前 `/var/lib/kubelet/device-plugins` 路径下已存在的 Unix 套接字。 通过这一事件,设备插件能够监测到其 Unix 套接字被删除,并重新对自身进行注册。
## 设备插件部署
设备插件可以手动部署,也可以作为 DaemonSet 进行部署。 以 DaemonSet 形式部署的好处是设备插件故障时,
Kubernetes能够重新启动 Pods 。 否则就需要额外的设备插件故障恢复机制。
目录 `/var/lib/kubelet/device-plugins` 需要访问特权,
所以设备插件必须在特权的安全上下文环境下运行。
如果设备插件以 DaemonSet 形式运行, `/var/lib/kubelet/device-plugins`
目录必须在插件的 [PodSpec](/docs/api-reference/{{< param "version" >}}/#podspec-v1-core) 中以 [Volume](/docs/api-reference/{{< param "version" >}}/#volume-v1-core) 的形式挂载。
## 示例
设备插件实现的示例,参考
[基于 COS 操作系统的 nvidia GPU 设备插件](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)。
{{% /capture %}}
@@ -1,117 +0,0 @@
---
title: 联邦
content_template: templates/concept
---
{{% capture overview %}}
本页面阐明了为何以及如何使用联邦创建Kubernetes集群。
{{% /capture %}}
{{% capture body %}}
## 为何使用联邦
联邦可以使多个集群的管理简单化。它提供了两个主要构件模块:
* 跨集群同步资源:联邦能够让资源在多个集群中同步。例如,你可以确保在多个集群中存在同样的部署。
* 跨集群发现:联邦能够在所有集群的后端自动配置DNS服务和负载均衡。例如,通过多个集群的后端,你可以确保全局的VIP或DNS记录可用。
联邦技术的其他应用场景:
* 高可用性:通过跨集群分摊负载,自动配置DNS服务和负载均衡,联邦将集群失败所带来的影响降到最低。
* 避免供应商锁定:跨集群使迁移应用程序变得更容易,联邦服务避免了供应商锁定。
只有在多个集群的场景下联邦服务才是有帮助的。这里列出了一些你会使用多个集群的原因:
* 降低延迟:在多个区域含有集群,可使用离用户最近的集群来服务用户,从而最大限度降低延迟。
* 故障隔离:对于故障隔离,也许有多个小的集群比有一个大的集群要更好一些(例如:一个云供应商的不同可用域里有多个集群)。详细信息请参阅[多集群指南](/docs/admin/multi-cluster)。
* 可伸缩性:对于单个kubernetes集群是有伸缩性限制的(但对于大多数用户来说并非如此。更多细节参考[Kubernetes扩展和性能目标](https://git.k8s.io/community/sig-scalability/goals.md))。
* [混合云](#混合云的能力):可以有多个集群,它们分别拥有不同的云供应商或者本地数据中心。
### 注意事项
虽然联邦有很多吸引人的场景,但这里还是有一些需要关注的事项:
* 增加网络的带宽和损耗:联邦控制面会监控所有的集群,来确保集群的当前状态与预期一致。那么当这些集群运行在一个或者多个云提供者的不同区域中,则会带来重大的网络损耗。
* 降低集群的隔离:当联邦控制面中存在一个故障时,会影响所有的集群。把联邦控制面的逻辑降到最小可以缓解这个问题。 无论何时,它都是kubernetes集群里控制面的代表。设计和实现也使其变得更安全,避免多集群运行中断。
* 完整性:联邦项目相对较新,还不是很成熟。不是所有资源都可用,且很多资源才刚刚开始。[Issue 38893](https://github.com/kubernetes/kubernetes/issues/38893) 列举了一些团队正忙于解决的系统已知问题。
### 混合云的能力
Kubernetes集群里的联邦包括运行在不同云供应商上的集群(例如,谷歌云、亚马逊),和本地部署的集群(例如,OpenStack)。只需在适当的云供应商和/或位置创建所需的所有集群,并将每个集群的API endpoint和凭据注册到您的联邦API服务中(详情参考[联邦管理指南](/docs/admin/federation/))。
在此之后,您的[API资源](#api资源)就可以跨越不同的集群和云供应商。
## 建立联邦
若要能联合多个集群,首先需要建立一个联邦控制面。参照[安装指南](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) 建立联邦控制面。
## API资源
控制面建立完成后,就可以开始创建联邦API资源了。
以下指南详细介绍了一些资源:
* [Cluster](/docs/tasks/administer-federation/cluster/)
* [ConfigMap](/docs/tasks/administer-federation/configmap/)
* [DaemonSets](/docs/tasks/administer-federation/daemonset/)
* [Deployment](/docs/tasks/administer-federation/deployment/)
* [Events](/docs/tasks/administer-federation/events/)
* [Ingress](/docs/tasks/administer-federation/ingress/)
* [Namespaces](/docs/tasks/administer-federation/namespaces/)
* [ReplicaSets](/docs/tasks/administer-federation/replicaset/)
* [Secrets](/docs/tasks/administer-federation/secret/)
* [Services](/docs/concepts/cluster-administration/federation-service-discovery/)
[API参考文档](/docs/reference/federation/)列举了联邦API服务支持的所有资源。
## 级联删除
Kubernetes1.6版本支持联邦资源级联删除。使用级联删除,即当删除联邦控制面的一个资源时,也删除了所有底层集群中的相应资源。
当使用REST API时,级联删除功能不是默认开启的。若使用REST API从联邦控制面删除一个资源时,要开启级联删除功能,即需配置选项 `DeleteOptions.orphanDependents=false`。使用`kubectl delete`使级联删除功能默认开启。使用`kubectl delete --cascade=false`禁用级联删除功能。
注意:Kubernetes1.5版本开始支持联邦资源子集的级联删除。
## 单个集群的范围
对于IaaS供应商如谷歌计算引擎或亚马逊网络服务,一个虚拟机存在于一个[](https://cloud.google.com/compute/docs/zones)或[可用域](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)中。
我们建议一个Kubernetes集群里的所有虚机应该在相同的可用域里,因为:
- 与单一的全局Kubernetes集群对比,该方式有较少的单点故障。
- 与跨可用域的集群对比,该方式更容易推断单区域集群的可用性属性。
- 当Kubernetes开发者设计一个系统(例如,对延迟、带宽或相关故障进行假设),他们也会假设所有的机器都在一个单一的数据中心,或者以其他方式紧密相连。
每个可用区域里包含多个集群当然是可以的,但是总的来说我们认为集群数越少越好。
偏爱较少集群数的原因是:
- 在某些情况下,在一个集群里有更多的节点,可以改进Pods的装箱问题(更少的资源碎片)。
- 减少操作开销(尽管随着OPS工具和流程的成熟而降低了这块的优势)。
- 为每个集群的固定资源花费降低开销,例如,使用apiserver的虚拟机(但是在全体集群开销中,中小型集群的开销占比要小的多)。
多集群的原因包括:
- 严格的安全性策略要求隔离一类工作与另一类工作(但是,请参见下面的集群分割)。
- 测试集群或其他集群软件直至最优的新Kubernetes版本发布。
## 选择合适的集群数
Kubernetes集群数量选择也许是一个相对静止的选择,因为对其重新审核的情况很少。相比之下,一个集群中的节点数和一个服务中的pods数可能会根据负载和增长频繁变化。
选择集群的数量,首先,需要决定哪些区域对于将要运行在Kubernetes上的服务,可以有足够的时间到达所有的终端用户(如果使用内容分发网络,则不需要考虑CDN-hosted内容的延迟需求)。法律问题也可能影响这一点。例如,拥有全球客户群的公司可能会对于在美国、欧盟、亚太和南非地区拥有集群起到决定权。使用`R`代表区域的数量。
其次,决定有多少集群在同一时间不可用,而一些仍然可用。使用`U`代表不可用的数量。如果不确定,最好选择1。
如果允许负载均衡在集群故障发生时将通信引导到任何区域,那么至少需要较大的`R``U + 1`集群。若非如此(例如,若要在集群故障发生时确保所有用户的低延迟),则需要`R * (U + 1)`集群(在每一个`R`区域里都有`U + 1`)。在任何情况下,尝试将每个集群放在不同的区域中。
最后,如果你的集群需求超过一个Kubernetes集群推荐的最大节点数,那么你可能需要更多的集群。Kubernetes1.3版本支持多达1000个节点的集群规模。
{{% /capture %}}
{{% capture whatsnext %}}
* 进一步学习[联邦提案](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)。
* 集群联邦参考该[配置指导](/docs/tutorials/federation/set-up-cluster-federation-kubefed/)。
* 查看[Kubecon2016浅谈联邦](https://www.youtube.com/watch?v=pq9lbkmxpS8)
{{% /capture %}}
@@ -1,64 +0,0 @@
---
title: Kubernetes 中的代理
content_template: templates/concept
---
{{% capture overview %}}
本文讲述了 Kubernetes 中所使用的代理。
{{% /capture %}}
{{% capture body %}}
## 代理
用户在使用 Kubernetes 的过程中可能遇到几种不同的代理(proxy):
1. [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api)
- 运行在用户的桌面或 pod 中
- 从本机地址到 Kubernetes apiserver 的代理
- 客户端到代理使用 HTTP 协议
- 代理到 apiserver 使用 HTTPS 协议
- 指向 apiserver
- 添加认证头信息
1. [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services)
- 是一个建立在 apiserver 内部的“堡垒”
- 将集群外部的用户与群集 IP 相连接,这些IP是无法通过其他方式访问的
- 运行在 apiserver 进程内
- 客户端到代理使用 HTTPS 协议 (如果配置 apiserver 使用 HTTP 协议,则使用 HTTP 协议)
- 通过可用信息进行选择,代理到目的地可能使用 HTTP 或 HTTPS 协议
- 可以用来访问 Node、 Pod 或 Service
- 当用来访问 Service 时,会进行负载均衡
1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips)
- 在每个节点上运行
- 代理 UDP 和 TCP
- 不支持 HTTP
- 提供负载均衡能力
- 只用来访问 Service
1. apiserver 之前的代理/负载均衡器:
- 在不同集群间的存在形式和实现不同 (如 nginx)
- 位于所有客户端和一个或多个 apiserver 之间
- 存在多个 apiserver 时,扮演负载均衡器的角色
1. 外部服务的云负载均衡器:
- 由一些云供应商提供 (如AWS ELB、 Google Cloud Load Balancer)
- Kubernetes service 为 `LoadBalancer` 类型时自动创建
- 只使用 UDP/TCP 协议
- 不同云供应商的实现不同。
Kubernetes 用户通常只需要关心前两种类型的代理,集群管理员通常需要确保后面几种类型的代理设置正确。
## 请求重定向
代理已经取代重定向功能,重定向已被弃用。
{{% /capture %}}

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