Merge branch 'master' into master
This commit is contained in:
@@ -65,7 +65,4 @@ $( document ).ready(function() {
|
|||||||
});
|
});
|
||||||
</script>
|
</script>
|
||||||
|
|
||||||
Sorry, this page was not found. :(
|
Sorry, this page was not found. :(
|
||||||
|
|
||||||
You can let us know by filling out the "I wish this page" text field at
|
|
||||||
the bottom of this page. Maybe try: "I wish this page _existed_."
|
|
||||||
|
|||||||
@@ -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
@@ -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
|
||||||
@@ -0,0 +1,15 @@
|
|||||||
|
.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.
|
||||||
|
|
||||||
|
build: ## Build site with production settings and put deliverables in _site.
|
||||||
|
jekyll build
|
||||||
|
|
||||||
|
build-preview: ## Build site with drafts and future posts enabled.
|
||||||
|
jekyll build --drafts --future
|
||||||
|
|
||||||
|
serve: ## Boot the development server.
|
||||||
|
jekyll serve
|
||||||
@@ -152,6 +152,32 @@ http://kubernetes-v1-3.github.io/
|
|||||||
|
|
||||||
Editing of these branches will kick off a build using Travis CI that auto-updates these URLs; you can monitor the build progress at [https://travis-ci.org/kubernetes/kubernetes.github.io](https://travis-ci.org/kubernetes/kubernetes.github.io).
|
Editing of these branches will kick off a build using Travis CI that auto-updates these URLs; you can monitor the build progress at [https://travis-ci.org/kubernetes/kubernetes.github.io](https://travis-ci.org/kubernetes/kubernetes.github.io).
|
||||||
|
|
||||||
|
## 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
|
## Partners
|
||||||
Kubernetes partners refers to the companies who contribute to the Kubernetes core codebase and/or extend their platform to support Kubernetes. Partners can get their logos added to the partner section of the [community page](http://k8s.io/community) by following the below steps and meeting the below logo specifications. Partners will also need to have a URL that is specific to integrating with Kubernetes ready; this URL will be the destination when the logo is clicked.
|
Kubernetes partners refers to the companies who contribute to the Kubernetes core codebase and/or extend their platform to support Kubernetes. Partners can get their logos added to the partner section of the [community page](http://k8s.io/community) by following the below steps and meeting the below logo specifications. Partners will also need to have a URL that is specific to integrating with Kubernetes ready; this URL will be the destination when the logo is clicked.
|
||||||
|
|
||||||
|
|||||||
+2
-2
@@ -161,6 +161,8 @@ toc:
|
|||||||
path: /docs/getting-started-guides/azure/
|
path: /docs/getting-started-guides/azure/
|
||||||
- title: Running Kubernetes on CenturyLink Cloud
|
- title: Running Kubernetes on CenturyLink Cloud
|
||||||
path: /docs/getting-started-guides/clc/
|
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
|
- title: Running Kubernetes on Custom Solutions
|
||||||
section:
|
section:
|
||||||
- title: Creating a Custom Cluster from Scratch
|
- title: Creating a Custom Cluster from Scratch
|
||||||
@@ -195,8 +197,6 @@ toc:
|
|||||||
path: /docs/getting-started-guides/openstack-heat/
|
path: /docs/getting-started-guides/openstack-heat/
|
||||||
- title: CoreOS on Multinode Cluster
|
- title: CoreOS on Multinode Cluster
|
||||||
path: /docs/getting-started-guides/coreos/coreos_multinode_cluster/
|
path: /docs/getting-started-guides/coreos/coreos_multinode_cluster/
|
||||||
- title: Fedora With Calico Networking
|
|
||||||
path: /docs/getting-started-guides/fedora/fedora-calico/
|
|
||||||
- title: rkt
|
- title: rkt
|
||||||
section:
|
section:
|
||||||
- title: Running Kubernetes with rkt
|
- title: Running Kubernetes with rkt
|
||||||
|
|||||||
@@ -18,8 +18,6 @@
|
|||||||
<a href="https://calendar.google.com/calendar/embed?src=nt2tcnbtbied3l6gi2h29slvc0%40group.calendar.google.com" class="calendar"><span>Events Calendar</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>
|
<div>
|
||||||
<span>I wish this page</span>
|
|
||||||
<input type="text" id="wishField" name="wishField" placeholder="enter your wish">
|
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
<div id="miceType" class="center">© {{ 'now' | date: "%Y" }} Kubernetes</div>
|
<div id="miceType" class="center">© {{ 'now' | date: "%Y" }} Kubernetes</div>
|
||||||
|
|||||||
@@ -43,7 +43,12 @@
|
|||||||
"permalink" : "http://kubernetes.github.io{{page.url}}"
|
"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'));
|
(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>{% endif %}
|
</script>
|
||||||
|
<a href="" onclick="window.open('https://github.com/kubernetes/kubernetes.github.io/issues/new?title=Issue%20with%20' +
|
||||||
|
window.location.pathname + '&body=Issue%20with%20' +
|
||||||
|
window.location.pathname)" class="button issue">Create Issue</a>
|
||||||
|
<a href="/editdocs#{{ page.path }}" class="button issue">Edit This Page</a>
|
||||||
|
{% endif %}
|
||||||
</div>
|
</div>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
|
|||||||
@@ -874,6 +874,12 @@ dd
|
|||||||
img
|
img
|
||||||
max-width: 100%
|
max-width: 100%
|
||||||
|
|
||||||
|
a.button
|
||||||
|
border-radius: 2px
|
||||||
|
|
||||||
|
a.issue
|
||||||
|
margin-left: 20px
|
||||||
|
|
||||||
.fixed footer
|
.fixed footer
|
||||||
position: fixed
|
position: fixed
|
||||||
bottom: 0
|
bottom: 0
|
||||||
|
|||||||
@@ -188,8 +188,15 @@ some OAuth2 providers, notably Azure Active Directory, Salesforce, and Google.
|
|||||||
The protocol's main extension of OAuth2 is an additional field returned with
|
The protocol's main extension of OAuth2 is an additional field returned with
|
||||||
the access token called an [ID Token](https://openid.net/specs/openid-connect-core-1_0.html#IDToken).
|
the access token called an [ID Token](https://openid.net/specs/openid-connect-core-1_0.html#IDToken).
|
||||||
This token is a JSON Web Token (JWT) with well known fields, such as a user's
|
This token is a JSON Web Token (JWT) with well known fields, such as a user's
|
||||||
email, signed by the server. When used as a bearer token, the API server can
|
email, signed by the server.
|
||||||
verify ID token's signature and determine the end users identity.
|
|
||||||
|
To identify the user, the authenticator uses the `id_token` (not the `access_token`)
|
||||||
|
from the OAuth2 [token response](https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse)
|
||||||
|
as a bearer token.
|
||||||
|
|
||||||
|
```
|
||||||
|
Authentication: Bearer (id_token)
|
||||||
|
```
|
||||||
|
|
||||||
To enable the plugin, pass the following required flags:
|
To enable the plugin, pass the following required flags:
|
||||||
|
|
||||||
@@ -223,12 +230,12 @@ Kubernetes does not provide an OpenID Connect Identity Provider.
|
|||||||
You can use an existing public OpenID Connect Identity Provider (such as Google, or [others](http://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)).
|
You can use an existing public OpenID Connect Identity Provider (such as Google, or [others](http://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)).
|
||||||
Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex), [Keycloak](https://github.com/keycloak/keycloak) or CloudFoundary [UAA](https://github.com/cloudfoundry/uaa).
|
Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex), [Keycloak](https://github.com/keycloak/keycloak) or CloudFoundary [UAA](https://github.com/cloudfoundry/uaa).
|
||||||
|
|
||||||
The provider needs to support [OpenID connect discovery]https://openid.net/specs/openid-connect-discovery-1_0.html); not all do.
|
The provider needs to support [OpenID connect discovery](https://openid.net/specs/openid-connect-discovery-1_0.html); not all do.
|
||||||
|
|
||||||
Setup instructions for specific systems:
|
Setup instructions for specific systems:
|
||||||
|
|
||||||
- [UAA]: http://apigee.com/about/blog/engineering/kubernetes-authentication-enterprise
|
- [UAA](http://apigee.com/about/blog/engineering/kubernetes-authentication-enterprise)
|
||||||
- [Dex]: https://speakerdeck.com/ericchiang/kubernetes-access-control-with-dex
|
- [Dex](https://speakerdeck.com/ericchiang/kubernetes-access-control-with-dex)
|
||||||
|
|
||||||
### Webhook Token Authentication
|
### Webhook Token Authentication
|
||||||
|
|
||||||
|
|||||||
@@ -204,7 +204,7 @@ As of 1.3 RBAC mode is in alpha and considered experimental.
|
|||||||
|
|
||||||
To use RBAC, you must both enable the authorization module with `--authorization-mode=RBAC`,
|
To use RBAC, you must both enable the authorization module with `--authorization-mode=RBAC`,
|
||||||
and [enable the API version](
|
and [enable the API version](
|
||||||
cluster-management.md/#Turn-on-or-off-an-API-version-for-your-cluster),
|
/docs/admin/cluster-management/#turn-on-or-off-an-api-version-for-your-cluster),
|
||||||
with a `--runtime-config=` that includes `rbac.authorization.k8s.io/v1alpha1`.
|
with a `--runtime-config=` that includes `rbac.authorization.k8s.io/v1alpha1`.
|
||||||
|
|
||||||
### Roles, RolesBindings, ClusterRoles, and ClusterRoleBindings
|
### Roles, RolesBindings, ClusterRoles, and ClusterRoleBindings
|
||||||
|
|||||||
@@ -111,11 +111,11 @@ to the corresponding `gcloud` commands.
|
|||||||
Examples:
|
Examples:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
gcloud container clusters create mytestcluster --zone=us-central1-b --enable-autoscaling=true --min-nodes=3 --max-nodes=10 --num-nodes=5
|
gcloud container clusters create mytestcluster --zone=us-central1-b --enable-autoscaling --min-nodes=3 --max-nodes=10 --num-nodes=5
|
||||||
```
|
```
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
gcloud container clusters update mytestcluster --enable-autoscaling=true --min-nodes=1 --max-nodes=15
|
gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=1 --max-nodes=15
|
||||||
```
|
```
|
||||||
|
|
||||||
**Cluster autoscaler expects that nodes have not been manually modified (e.g. by adding labels via kubectl) as those properties would not be propagated to the new nodes within the same instance group.**
|
**Cluster autoscaler expects that nodes have not been manually modified (e.g. by adding labels via kubectl) as those properties would not be propagated to the new nodes within the same instance group.**
|
||||||
|
|||||||
@@ -160,7 +160,7 @@ Lars Kellogg-Stedman.
|
|||||||
|
|
||||||
### Weave Net from Weaveworks
|
### Weave Net from Weaveworks
|
||||||
|
|
||||||
[Weave Net](https://www.weave.works/documentation/net-1-6-0-introducing-weave/) is a
|
[Weave Net](https://www.weave.works/products/weave-net/) is a
|
||||||
resilient and simple to use network for Kubernetes and its hosted applications.
|
resilient and simple to use network for Kubernetes and its hosted applications.
|
||||||
Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-plugin/)
|
Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-plugin/)
|
||||||
or stand-alone. In either version, it doesn’t require any configuration or extra code
|
or stand-alone. In either version, it doesn’t require any configuration or extra code
|
||||||
|
|||||||
@@ -36,8 +36,7 @@ it to [support other log format](/docs/admin/node-problem/#support-other-log-for
|
|||||||
|
|
||||||
## Enable/Disable in GCE cluster
|
## Enable/Disable in GCE cluster
|
||||||
|
|
||||||
Node problem detector is [running as a cluster
|
Node problem detector is [running as a cluster addon](cluster-large.md/#Addon-Resources) enabled by default in the
|
||||||
addon](/docs/admin/cluster-large/#addon-resources) enabled by default in the
|
|
||||||
gce cluster.
|
gce cluster.
|
||||||
|
|
||||||
You can enable/disable it by setting the environment variable
|
You can enable/disable it by setting the environment variable
|
||||||
|
|||||||
@@ -48,7 +48,7 @@ For example, this is how to start a simple web server as a static pod:
|
|||||||
EOF
|
EOF
|
||||||
```
|
```
|
||||||
|
|
||||||
2. Configure your kubelet daemon on the node to use this directory by running it with `--config=/etc/kubelet.d/` argument. On Fedora Fedora 21 with Kubernetes 0.17 edit `/etc/kubernetes/kubelet` to include this line:
|
2. Configure your kubelet daemon on the node to use this directory by running it with `--config=/etc/kubelet.d/` argument. On Fedora edit `/etc/kubernetes/kubelet` to include this line:
|
||||||
|
|
||||||
```conf
|
```conf
|
||||||
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --config=/etc/kubelet.d/"
|
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --config=/etc/kubelet.d/"
|
||||||
@@ -56,7 +56,7 @@ For example, this is how to start a simple web server as a static pod:
|
|||||||
|
|
||||||
Instructions for other distributions or Kubernetes installations may vary.
|
Instructions for other distributions or Kubernetes installations may vary.
|
||||||
|
|
||||||
3. Restart kubelet. On Fedora 21, this is:
|
3. Restart kubelet. On Fedora, this is:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
[root@my-node1 ~] $ systemctl restart kubelet
|
[root@my-node1 ~] $ systemctl restart kubelet
|
||||||
|
|||||||
@@ -43,7 +43,7 @@ export AZURE_SUBSCRIPTION_ID="<subscription-guid>"
|
|||||||
export AZURE_TENANT_ID="<tenant-guid>" # only needed for Kubernetes < v1.3.0.
|
export AZURE_TENANT_ID="<tenant-guid>" # only needed for Kubernetes < v1.3.0.
|
||||||
```
|
```
|
||||||
|
|
||||||
These values can be overriden by setting them in `cluster/azure/config-default.sh` or as environment variables. They are shown here with their default values:
|
These values can be overridden by setting them in `cluster/azure/config-default.sh` or as environment variables. They are shown here with their default values:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
export AZURE_DEPLOY_ID="" # autogenerated if blank
|
export AZURE_DEPLOY_ID="" # autogenerated if blank
|
||||||
|
|||||||
@@ -251,9 +251,9 @@ kubectl cluster-info
|
|||||||
|
|
||||||
### Accessing the cluster programmatically
|
### Accessing the cluster programmatically
|
||||||
|
|
||||||
It's possible to use the locally-stored client certificates to access the api server. For example, you may want to use any of the [Kubernetes API client libraries](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/client-libraries.md) to program against your Kubernetes cluster in the programming language of your choice.
|
It's possible to use the locally stored client certificates to access the api server. For example, you may want to use any of the [Kubernetes API client libraries](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/client-libraries.md) to program against your Kubernetes cluster in the programming language of your choice.
|
||||||
|
|
||||||
To demostrate how to use these locally stored certificates, we provide the folowing example of using ```curl``` to communicate to the master api server via https:
|
To demonstrate how to use these locally stored certificates, we provide the following example of using ```curl``` to communicate to the master api server via https:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
curl \
|
curl \
|
||||||
@@ -267,7 +267,7 @@ distributed with OSX.
|
|||||||
|
|
||||||
### Accessing the cluster with a browser
|
### Accessing the cluster with a browser
|
||||||
|
|
||||||
We install two UIs on Kubernetes. The orginal KubeUI and [the newer kube
|
We install two UIs on Kubernetes. The original KubeUI and [the newer kube
|
||||||
dashboard](/docs/user-guide/ui/). When you create a cluster, the script should output URLs for these
|
dashboard](/docs/user-guide/ui/). When you create a cluster, the script should output URLs for these
|
||||||
interfaces like this:
|
interfaces like this:
|
||||||
|
|
||||||
|
|||||||
@@ -39,7 +39,7 @@ Download the stable CoreOS bootable ISO from the [CoreOS website](https://coreos
|
|||||||
|
|
||||||
1. Once you've downloaded the ISO image, burn the ISO to a CD/DVD/USB key and boot from it (if using a virtual machine you can boot directly from the ISO). Once booted, you should be automatically logged in as the `core` user at the terminal. At this point CoreOS is running from the ISO and it hasn't been installed yet.
|
1. Once you've downloaded the ISO image, burn the ISO to a CD/DVD/USB key and boot from it (if using a virtual machine you can boot directly from the ISO). Once booted, you should be automatically logged in as the `core` user at the terminal. At this point CoreOS is running from the ISO and it hasn't been installed yet.
|
||||||
|
|
||||||
2. *On another machine*, download the the [master cloud-config template](https://raw.githubusercontent.com/projectcalico/calico-cni/k8s-1.1-docs/samples/kubernetes/cloud-config/master-config-template.yaml) and save it as `master-config.yaml`.
|
2. *On another machine*, download the [master cloud-config template](https://raw.githubusercontent.com/projectcalico/calico-cni/k8s-1.1-docs/samples/kubernetes/cloud-config/master-config-template.yaml) and save it as `master-config.yaml`.
|
||||||
|
|
||||||
3. Replace the following variables in the `master-config.yaml` file.
|
3. Replace the following variables in the `master-config.yaml` file.
|
||||||
|
|
||||||
|
|||||||
@@ -23,7 +23,7 @@ Deploy a CoreOS running Kubernetes environment. This particular guide is made to
|
|||||||
* /tftpboot/pxelinux.0/(MAC) -> linked to Linux image config file
|
* /tftpboot/pxelinux.0/(MAC) -> linked to Linux image config file
|
||||||
2. Update per install the link for pxelinux
|
2. Update per install the link for pxelinux
|
||||||
3. Update the DHCP config to reflect the host needing deployment
|
3. Update the DHCP config to reflect the host needing deployment
|
||||||
4. Setup nodes to deploy CoreOS creating a etcd cluster.
|
4. Setup nodes to deploy CoreOS creating an etcd cluster.
|
||||||
5. Have no access to the public [etcd discovery tool](https://discovery.etcd.io/).
|
5. Have no access to the public [etcd discovery tool](https://discovery.etcd.io/).
|
||||||
6. Installing the CoreOS slaves to become Kubernetes nodes.
|
6. Installing the CoreOS slaves to become Kubernetes nodes.
|
||||||
|
|
||||||
@@ -98,7 +98,7 @@ Now you should have a working PXELINUX setup to image CoreOS nodes. You can veri
|
|||||||
|
|
||||||
This section describes how to setup the CoreOS images to live alongside a pre-existing PXELINUX environment.
|
This section describes how to setup the CoreOS images to live alongside a pre-existing PXELINUX environment.
|
||||||
|
|
||||||
1. Find or create the TFTP root directory that everything will be based off of.
|
1. Find or create the TFTP root directory that everything will be based on.
|
||||||
* For this document we will assume `/tftpboot/` is our root directory.
|
* For this document we will assume `/tftpboot/` is our root directory.
|
||||||
2. Once we know and have our tftp root directory we will create a new directory structure for our CoreOS images.
|
2. Once we know and have our tftp root directory we will create a new directory structure for our CoreOS images.
|
||||||
3. Download the CoreOS PXE files provided by the CoreOS team.
|
3. Download the CoreOS PXE files provided by the CoreOS team.
|
||||||
|
|||||||
@@ -65,7 +65,7 @@ Each of these options are overridable by `export`ing the values before running t
|
|||||||
|
|
||||||
The first step in the process is to initialize the master node.
|
The first step in the process is to initialize the master node.
|
||||||
|
|
||||||
Clone the `kube-deploy` repo, and run [master.sh](master.sh) on the master machine _with root_:
|
Clone the `kube-deploy` repo, and run `master.sh` on the master machine _with root_:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
$ git clone https://github.com/kubernetes/kube-deploy
|
$ git clone https://github.com/kubernetes/kube-deploy
|
||||||
@@ -82,7 +82,7 @@ Lastly, it launches `kubelet` in the main docker daemon, and the `kubelet` in tu
|
|||||||
|
|
||||||
Once your master is up and running you can add one or more workers on different machines.
|
Once your master is up and running you can add one or more workers on different machines.
|
||||||
|
|
||||||
Clone the `kube-deploy` repo, and run [worker.sh](worker.sh) on the worker machine _with root_:
|
Clone the `kube-deploy` repo, and run `worker.sh` on the worker machine _with root_:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
$ git clone https://github.com/kubernetes/kube-deploy
|
$ git clone https://github.com/kubernetes/kube-deploy
|
||||||
|
|||||||
@@ -1,313 +0,0 @@
|
|||||||
---
|
|
||||||
assignees:
|
|
||||||
- caesarxuchao
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
This guide will walk you through the process of getting a Kubernetes Fedora cluster running on Digital Ocean with networking powered by Calico networking.
|
|
||||||
It will cover the installation and configuration of the following systemd processes on the following hosts:
|
|
||||||
|
|
||||||
Kubernetes Master:
|
|
||||||
|
|
||||||
- `kube-apiserver`
|
|
||||||
- `kube-controller-manager`
|
|
||||||
- `kube-scheduler`
|
|
||||||
- `etcd`
|
|
||||||
- `docker`
|
|
||||||
- `calico-node`
|
|
||||||
|
|
||||||
Kubernetes Node:
|
|
||||||
|
|
||||||
- `kubelet`
|
|
||||||
- `kube-proxy`
|
|
||||||
- `docker`
|
|
||||||
- `calico-node`
|
|
||||||
|
|
||||||
For this demo, we will be setting up one Master and one Node with the following information:
|
|
||||||
|
|
||||||
| Hostname | IP |
|
|
||||||
|-------------|-------------|
|
|
||||||
| kube-master |10.134.251.56|
|
|
||||||
| kube-node-1 |10.134.251.55|
|
|
||||||
|
|
||||||
This guide is scalable to multiple nodes provided you [configure interface-cbr0 with its own subnet on each Node](#configure-the-virtual-interface---cbr0)
|
|
||||||
and [add an entry to /etc/hosts for each host](#setup-communication-between-hosts).
|
|
||||||
|
|
||||||
Ensure you substitute the IP Addresses and Hostnames used in this guide with ones in your own setup.
|
|
||||||
|
|
||||||
* TOC
|
|
||||||
{:toc}
|
|
||||||
|
|
||||||
## Prerequisites
|
|
||||||
|
|
||||||
You need two or more Fedora 22 droplets on Digital Ocean with [Private Networking](https://www.digitalocean.com/community/tutorials/how-to-set-up-and-use-digitalocean-private-networking) enabled.
|
|
||||||
|
|
||||||
## Setup Communication Between Hosts
|
|
||||||
|
|
||||||
Digital Ocean private networking configures a private network on eth1 for each host. To simplify communication between the hosts, we will add an entry to /etc/hosts
|
|
||||||
so that all hosts in the cluster can hostname-resolve one another to this interface. **It is important that the hostname resolves to this interface instead of eth0, as
|
|
||||||
all Kubernetes and Calico services will be running on it.**
|
|
||||||
|
|
||||||
```shell
|
|
||||||
echo "10.134.251.56 kube-master" >> /etc/hosts
|
|
||||||
echo "10.134.251.55 kube-node-1" >> /etc/hosts
|
|
||||||
```
|
|
||||||
|
|
||||||
> Make sure that communication works between kube-master and each kube-node by using a utility such as ping.
|
|
||||||
|
|
||||||
## Setup Master
|
|
||||||
|
|
||||||
### Install etcd
|
|
||||||
|
|
||||||
* Both Calico and Kubernetes use etcd as their datastore. We will run etcd on Master and point all Kubernetes and Calico services at it.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
yum -y install etcd
|
|
||||||
```
|
|
||||||
|
|
||||||
* Edit `/etc/etcd/etcd.conf`
|
|
||||||
|
|
||||||
```conf
|
|
||||||
ETCD_LISTEN_CLIENT_URLS="http://kube-master:4001"
|
|
||||||
|
|
||||||
ETCD_ADVERTISE_CLIENT_URLS="http://kube-master:4001"
|
|
||||||
```
|
|
||||||
|
|
||||||
### Install Kubernetes
|
|
||||||
|
|
||||||
* Run the following command on Master to install the latest Kubernetes (as well as docker):
|
|
||||||
|
|
||||||
```shell
|
|
||||||
yum -y install kubernetes
|
|
||||||
```
|
|
||||||
|
|
||||||
* Edit `/etc/kubernetes/config `
|
|
||||||
|
|
||||||
```conf
|
|
||||||
# How the controller-manager, scheduler, and proxy find the apiserver
|
|
||||||
KUBE_MASTER="--master=http://kube-master:8080"
|
|
||||||
```
|
|
||||||
|
|
||||||
* Edit `/etc/kubernetes/apiserver`
|
|
||||||
|
|
||||||
```conf
|
|
||||||
# The address on the local server to listen to.
|
|
||||||
KUBE_API_ADDRESS="--insecure-bind-address=0.0.0.0"
|
|
||||||
|
|
||||||
KUBE_ETCD_SERVERS="--etcd-servers=http://kube-master:4001"
|
|
||||||
|
|
||||||
# Remove ServiceAccount from this line to run without API Tokens
|
|
||||||
KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ResourceQuota"
|
|
||||||
```
|
|
||||||
|
|
||||||
* Create /var/run/kubernetes on master:
|
|
||||||
|
|
||||||
```shell
|
|
||||||
mkdir /var/run/kubernetes
|
|
||||||
chown kube:kube /var/run/kubernetes
|
|
||||||
chmod 750 /var/run/kubernetes
|
|
||||||
```
|
|
||||||
|
|
||||||
* Start the appropriate services on master:
|
|
||||||
|
|
||||||
```shell
|
|
||||||
for SERVICE in etcd kube-apiserver kube-controller-manager kube-scheduler; do
|
|
||||||
systemctl restart $SERVICE
|
|
||||||
systemctl enable $SERVICE
|
|
||||||
systemctl status $SERVICE
|
|
||||||
done
|
|
||||||
```
|
|
||||||
|
|
||||||
### Install Calico
|
|
||||||
|
|
||||||
Next, we'll launch Calico on Master to allow communication between Pods and any services running on the Master.
|
|
||||||
* Install calicoctl, the calico configuration tool.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
wget https://github.com/Metaswitch/calico-docker/releases/download/v0.5.5/calicoctl
|
|
||||||
chmod +x ./calicoctl
|
|
||||||
sudo mv ./calicoctl /usr/bin
|
|
||||||
```
|
|
||||||
|
|
||||||
* Create `/etc/systemd/system/calico-node.service`
|
|
||||||
|
|
||||||
```conf
|
|
||||||
[Unit]
|
|
||||||
Description=calicoctl node
|
|
||||||
Requires=docker.service
|
|
||||||
After=docker.service
|
|
||||||
|
|
||||||
[Service]
|
|
||||||
User=root
|
|
||||||
Environment="ETCD_AUTHORITY=kube-master:4001"
|
|
||||||
PermissionsStartOnly=true
|
|
||||||
ExecStartPre=/usr/bin/calicoctl checksystem --fix
|
|
||||||
ExecStart=/usr/bin/calicoctl node --ip=10.134.251.56 --detach=false
|
|
||||||
|
|
||||||
[Install]
|
|
||||||
WantedBy=multi-user.target
|
|
||||||
```
|
|
||||||
|
|
||||||
>Be sure to substitute `--ip=10.134.251.56` with your Master's eth1 IP Address.
|
|
||||||
|
|
||||||
* Start Calico
|
|
||||||
|
|
||||||
```shell
|
|
||||||
systemctl enable calico-node.service
|
|
||||||
systemctl start calico-node.service
|
|
||||||
```
|
|
||||||
|
|
||||||
>Starting calico for the first time may take a few minutes as the calico-node docker image is downloaded.
|
|
||||||
|
|
||||||
## Setup Node
|
|
||||||
|
|
||||||
### Configure the Virtual Interface - cbr0
|
|
||||||
|
|
||||||
By default, docker will create and run on a virtual interface called `docker0`. This interface is automatically assigned the address range 172.17.42.1/16.
|
|
||||||
In order to set our own address range, we will create a new virtual interface called `cbr0` and then start docker on it.
|
|
||||||
|
|
||||||
* Add a virtual interface by creating `/etc/sysconfig/network-scripts/ifcfg-cbr0`:
|
|
||||||
|
|
||||||
```conf
|
|
||||||
DEVICE=cbr0
|
|
||||||
TYPE=Bridge
|
|
||||||
IPADDR=192.168.1.1
|
|
||||||
NETMASK=255.255.255.0
|
|
||||||
ONBOOT=yes
|
|
||||||
BOOTPROTO=static
|
|
||||||
```
|
|
||||||
|
|
||||||
>**Note for Multi-Node Clusters:** Each node should be assigned an IP address on a unique subnet. In this example, node-1 is using 192.168.1.1/24,
|
|
||||||
so node-2 should be assigned another pool on the 192.168.x.0/24 subnet, e.g. 192.168.2.1/24.
|
|
||||||
|
|
||||||
* Ensure that your system has bridge-utils installed. Then, restart the networking daemon to activate the new interface
|
|
||||||
|
|
||||||
```shell
|
|
||||||
systemctl restart network.service
|
|
||||||
```
|
|
||||||
|
|
||||||
### Install Docker
|
|
||||||
|
|
||||||
* Install Docker
|
|
||||||
|
|
||||||
```shell
|
|
||||||
yum -y install docker
|
|
||||||
```
|
|
||||||
|
|
||||||
* Configure docker to run on `cbr0` by editing `/etc/sysconfig/docker-network`:
|
|
||||||
|
|
||||||
```conf
|
|
||||||
DOCKER_NETWORK_OPTIONS="--bridge=cbr0 --iptables=false --ip-masq=false"
|
|
||||||
```
|
|
||||||
|
|
||||||
* Start docker
|
|
||||||
|
|
||||||
```shell
|
|
||||||
systemctl start docker
|
|
||||||
```
|
|
||||||
|
|
||||||
### Install Calico
|
|
||||||
|
|
||||||
* Install calicoctl, the calico configuration tool.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
wget https://github.com/Metaswitch/calico-docker/releases/download/v0.5.5/calicoctl
|
|
||||||
chmod +x ./calicoctl
|
|
||||||
sudo mv ./calicoctl /usr/bin
|
|
||||||
```
|
|
||||||
|
|
||||||
* Create `/etc/systemd/system/calico-node.service`
|
|
||||||
|
|
||||||
```conf
|
|
||||||
[Unit]
|
|
||||||
Description=calicoctl node
|
|
||||||
Requires=docker.service
|
|
||||||
After=docker.service
|
|
||||||
|
|
||||||
[Service]
|
|
||||||
User=root
|
|
||||||
Environment="ETCD_AUTHORITY=kube-master:4001"
|
|
||||||
PermissionsStartOnly=true
|
|
||||||
ExecStartPre=/usr/bin/calicoctl checksystem --fix
|
|
||||||
ExecStart=/usr/bin/calicoctl node --ip=10.134.251.55 --detach=false --kubernetes
|
|
||||||
|
|
||||||
[Install]
|
|
||||||
WantedBy=multi-user.target
|
|
||||||
```
|
|
||||||
|
|
||||||
> Note: You must replace the IP address with your node's eth1 IP Address!
|
|
||||||
|
|
||||||
* Start Calico
|
|
||||||
|
|
||||||
```shell
|
|
||||||
systemctl enable calico-node.service
|
|
||||||
systemctl start calico-node.service
|
|
||||||
```
|
|
||||||
|
|
||||||
* Configure the IP Address Pool
|
|
||||||
|
|
||||||
Most Kubernetes application deployments will require communication between Pods and the kube-apiserver on Master. On a standard Digital
|
|
||||||
Ocean Private Network, requests sent from Pods to the kube-apiserver will not be returned as the networking fabric will drop response packets
|
|
||||||
destined for any 192.168.0.0/16 address. To resolve this, you can have calicoctl add a masquerade rule to all outgoing traffic on the node:
|
|
||||||
|
|
||||||
```shell
|
|
||||||
ETCD_AUTHORITY=kube-master:4001 calicoctl pool add 192.168.0.0/16 --nat-outgoing
|
|
||||||
```
|
|
||||||
|
|
||||||
### Install Kubernetes
|
|
||||||
|
|
||||||
* First, install Kubernetes.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
yum -y install kubernetes
|
|
||||||
```
|
|
||||||
|
|
||||||
* Edit `/etc/kubernetes/config`
|
|
||||||
|
|
||||||
```conf
|
|
||||||
# How the controller-manager, scheduler, and proxy find the apiserver
|
|
||||||
KUBE_MASTER="--master=http://kube-master:8080"
|
|
||||||
```
|
|
||||||
|
|
||||||
* Edit `/etc/kubernetes/kubelet`
|
|
||||||
|
|
||||||
We'll pass in an extra parameter - `--network-plugin=calico` to tell the Kubelet to use the Calico networking plugin. Additionally, we'll add two
|
|
||||||
environment variables that will be used by the Calico networking plugin.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
# The address for the info server to serve on (set to 0.0.0.0 or "" for all interfaces)
|
|
||||||
KUBELET_ADDRESS="--address=0.0.0.0"
|
|
||||||
|
|
||||||
# You may leave this blank to use the actual hostname
|
|
||||||
# KUBELET_HOSTNAME="--hostname-override=127.0.0.1"
|
|
||||||
|
|
||||||
# location of the api-server
|
|
||||||
KUBELET_API_SERVER="--api-servers=http://kube-master:8080"
|
|
||||||
|
|
||||||
# Add your own!
|
|
||||||
KUBELET_ARGS="--network-plugin=calico"
|
|
||||||
|
|
||||||
# The following are variables which the kubelet will pass to the calico-networking plugin
|
|
||||||
ETCD_AUTHORITY="kube-master:4001"
|
|
||||||
KUBE_API_ROOT="http://kube-master:8080/api/v1"
|
|
||||||
```
|
|
||||||
|
|
||||||
* Start Kubernetes on the node.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
for SERVICE in kube-proxy kubelet; do
|
|
||||||
systemctl restart $SERVICE
|
|
||||||
systemctl enable $SERVICE
|
|
||||||
systemctl status $SERVICE
|
|
||||||
done
|
|
||||||
```
|
|
||||||
|
|
||||||
## Check Running Cluster
|
|
||||||
|
|
||||||
The cluster should be running! Check that your nodes are reporting as such:
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl get nodes
|
|
||||||
NAME LABELS STATUS
|
|
||||||
kube-node-1 kubernetes.io/hostname=kube-node-1 Ready
|
|
||||||
```
|
|
||||||
@@ -39,6 +39,8 @@ clusters.
|
|||||||
|
|
||||||
[Stackpoint.io](https://stackpoint.io) provides Kubernetes infrastructure automation and management for multiple public clouds.
|
[Stackpoint.io](https://stackpoint.io) provides Kubernetes infrastructure automation and management for multiple public clouds.
|
||||||
|
|
||||||
|
[AppsCode.com](https://appscode.com/products/cloud-deployment/) provides managed Kubernetes clusters for various public clouds (including AWS and Google Cloud Platform).
|
||||||
|
|
||||||
### Turn-key Cloud Solutions
|
### Turn-key Cloud Solutions
|
||||||
|
|
||||||
These solutions allow you to create Kubernetes clusters on a range of Cloud IaaS providers with only a
|
These solutions allow you to create Kubernetes clusters on a range of Cloud IaaS providers with only a
|
||||||
@@ -49,6 +51,7 @@ few commands, and have active community support.
|
|||||||
- [Azure](/docs/getting-started-guides/coreos/azure/) (Weave-based, contributed by WeaveWorks employees)
|
- [Azure](/docs/getting-started-guides/coreos/azure/) (Weave-based, contributed by WeaveWorks employees)
|
||||||
- [Azure](/docs/getting-started-guides/azure/) (Flannel-based, contributed by Microsoft employee)
|
- [Azure](/docs/getting-started-guides/azure/) (Flannel-based, contributed by Microsoft employee)
|
||||||
- [CenturyLink Cloud](/docs/getting-started-guides/clc)
|
- [CenturyLink Cloud](/docs/getting-started-guides/clc)
|
||||||
|
- [IBM SoftLayer](https://github.com/patrocinio/kubernetes-softlayer)
|
||||||
|
|
||||||
### Custom Solutions
|
### Custom Solutions
|
||||||
|
|
||||||
@@ -116,6 +119,7 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs
|
|||||||
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
|
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
|
||||||
GKE | | | GCE | [docs](https://cloud.google.com/container-engine) | ['œ“][3] | Commercial
|
GKE | | | GCE | [docs](https://cloud.google.com/container-engine) | ['œ“][3] | Commercial
|
||||||
Stackpoint.io | | multi-support | multi-support | [docs](http://www.stackpointcloud.com) | | Commercial
|
Stackpoint.io | | multi-support | multi-support | [docs](http://www.stackpointcloud.com) | | Commercial
|
||||||
|
AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | | Commercial
|
||||||
GCE | Saltstack | Debian | GCE | [docs](/docs/getting-started-guides/gce) | ['œ“][1] | Project
|
GCE | Saltstack | Debian | GCE | [docs](/docs/getting-started-guides/gce) | ['œ“][1] | Project
|
||||||
Azure | CoreOS | CoreOS | Weave | [docs](/docs/getting-started-guides/coreos/azure/) | | Community ([@errordeveloper](https://github.com/errordeveloper), [@squillace](https://github.com/squillace), [@chanezon](https://github.com/chanezon), [@crossorigin](https://github.com/crossorigin))
|
Azure | CoreOS | CoreOS | Weave | [docs](/docs/getting-started-guides/coreos/azure/) | | Community ([@errordeveloper](https://github.com/errordeveloper), [@squillace](https://github.com/squillace), [@chanezon](https://github.com/chanezon), [@crossorigin](https://github.com/crossorigin))
|
||||||
Azure | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/azure) | | Community ([@colemickens](https://github.com/colemickens))
|
Azure | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/azure) | | Community ([@colemickens](https://github.com/colemickens))
|
||||||
|
|||||||
@@ -93,7 +93,7 @@ asks you to configure your view of the ingested logs. Select the option for
|
|||||||
timeseries values and select `@timestamp`. On the following page select the
|
timeseries values and select `@timestamp`. On the following page select the
|
||||||
`Discover` tab and then you should be able to see the ingested logs.
|
`Discover` tab and then you should be able to see the ingested logs.
|
||||||
You can set the refresh interval to 5 seconds to have the logs
|
You can set the refresh interval to 5 seconds to have the logs
|
||||||
regulary refreshed.
|
regularly refreshed.
|
||||||
|
|
||||||
Here is a typical view of ingested logs from the Kibana viewer:
|
Here is a typical view of ingested logs from the Kibana viewer:
|
||||||
|
|
||||||
|
|||||||
@@ -64,7 +64,7 @@ RUN npm install
|
|||||||
CMD ["node", "app.js"]
|
CMD ["node", "app.js"]
|
||||||
```
|
```
|
||||||
|
|
||||||
A `Dockerfile` is pretty self explanatory, and this one is dead simple.
|
A `Dockerfile` is pretty self-explanatory, and this one is dead simple.
|
||||||
|
|
||||||
First, it uses the official Node.js LTS image as the base image.
|
First, it uses the official Node.js LTS image as the base image.
|
||||||
|
|
||||||
|
|||||||
@@ -86,7 +86,7 @@ If you do not have your environment variables set, or do not want them consumed,
|
|||||||
- **[config-default.sh](http://releases.k8s.io/{{page.githubbranch}}/cluster/openstack-heat/config-default.sh)** Sets all parameters needed for heat template.
|
- **[config-default.sh](http://releases.k8s.io/{{page.githubbranch}}/cluster/openstack-heat/config-default.sh)** Sets all parameters needed for heat template.
|
||||||
- **[config-image.sh](http://releases.k8s.io/{{page.githubbranch}}/cluster/openstack-heat/config-image.sh)** Sets parameters needed to download and create new OpenStack image via glance.
|
- **[config-image.sh](http://releases.k8s.io/{{page.githubbranch}}/cluster/openstack-heat/config-image.sh)** Sets parameters needed to download and create new OpenStack image via glance.
|
||||||
- **[openrc-default.sh](http://releases.k8s.io/{{page.githubbranch}}/cluster/openstack-heat/openrc-default.sh)** Sets environment variables for communicating to OpenStack. These are consumed by the cli tools (heat, glance, swift, nova).
|
- **[openrc-default.sh](http://releases.k8s.io/{{page.githubbranch}}/cluster/openstack-heat/openrc-default.sh)** Sets environment variables for communicating to OpenStack. These are consumed by the cli tools (heat, glance, swift, nova).
|
||||||
- **[openrc-swift.sh](http://releases.k8s.io/{{page.githubbranch}}/cluster/openstack-heat/openrc-swift.sh)** Some OpenStack setups require the use of seperate swift credentials. Put those credentials in this file.
|
- **[openrc-swift.sh](http://releases.k8s.io/{{page.githubbranch}}/cluster/openstack-heat/openrc-swift.sh)** Some OpenStack setups require the use of separate swift credentials. Put those credentials in this file.
|
||||||
|
|
||||||
Please see the contents of these files for documentation regarding each variable's function.
|
Please see the contents of these files for documentation regarding each variable's function.
|
||||||
|
|
||||||
|
|||||||
@@ -57,6 +57,7 @@ on how flags are set on various components.
|
|||||||
|
|
||||||
### Network
|
### Network
|
||||||
|
|
||||||
|
#### Network Connectivity
|
||||||
Kubernetes has a distinctive [networking model](/docs/admin/networking).
|
Kubernetes has a distinctive [networking model](/docs/admin/networking).
|
||||||
|
|
||||||
Kubernetes allocates an IP address to each pod. When creating a cluster, you
|
Kubernetes allocates an IP address to each pod. When creating a cluster, you
|
||||||
@@ -66,23 +67,35 @@ the node is added. A process in one pod should be able to communicate with
|
|||||||
another pod using the IP of the second pod. This connectivity can be
|
another pod using the IP of the second pod. This connectivity can be
|
||||||
accomplished in two ways:
|
accomplished in two ways:
|
||||||
|
|
||||||
- Configure network to route Pod IPs
|
- **Using an overlay network**
|
||||||
- Harder to setup from scratch.
|
- An overlay network obscures the underlying network architecture from the
|
||||||
- Google Compute Engine ([GCE](/docs/getting-started-guides/gce)) and [AWS](/docs/getting-started-guides/aws) guides use this approach.
|
pod network through traffic encapsulation (e.g vxlan).
|
||||||
- Need to make the Pod IPs routable by programming routers, switches, etc.
|
- Encapsulation reduces performance, though exactly how much depends on your solution.
|
||||||
- Can be configured external to Kubernetes, or can implement in the "Routes" interface of a Cloud Provider module.
|
- **Without an overlay network**
|
||||||
- Generally highest performance.
|
- Configure the underlying network fabric (switches, routers, etc) to be aware of pod IP addresses.
|
||||||
- Create an Overlay network
|
- This does not require the encapsulation provided by an overlay, and so can achieve
|
||||||
- Easier to setup
|
better performance.
|
||||||
- Traffic is encapsulated, so per-pod IPs are routable.
|
|
||||||
- Examples:
|
Which method you choose depends on your environment and requirements. There are various ways
|
||||||
|
to implement one of the above options:
|
||||||
|
|
||||||
|
- **Use a network plugin which is called by Kubernetes**
|
||||||
|
- Kubernetes supports the [CNI](https://github.com/containernetworking/cni) network plugin interface.
|
||||||
|
- There are a number of solutions which provide plugins for Kubernetes:
|
||||||
- [Flannel](https://github.com/coreos/flannel)
|
- [Flannel](https://github.com/coreos/flannel)
|
||||||
|
- [Calico](http://https://github.com/projectcalico/calico-containers)
|
||||||
- [Weave](http://weave.works/)
|
- [Weave](http://weave.works/)
|
||||||
- [Open vSwitch (OVS)](http://openvswitch.org/)
|
- [Open vSwitch (OVS)](http://openvswitch.org/)
|
||||||
- Does not require "Routes" portion of Cloud Provider module.
|
- [More found here](/docs/admin/networking#how-to-achieve-this)
|
||||||
- Reduced performance (exactly how much depends on your solution).
|
- You can also write your own.
|
||||||
|
- **Compile support directly into Kubernetes**
|
||||||
|
- This can be done by implementing the "Routes" interface of a Cloud Provider module.
|
||||||
|
- The Google Compute Engine ([GCE](/docs/getting-started-guides/gce)) and [AWS](/docs/getting-started-guides/aws) guides use this approach.
|
||||||
|
- **Configure the network external to Kubernetes**
|
||||||
|
- This can be done by manually running commands, or through a set of externally maintained scripts.
|
||||||
|
- You have to implement this yourself, but it can give you an extra degree of flexibility.
|
||||||
|
|
||||||
You need to select an address range for the Pod IPs.
|
You will need to select an address range for the Pod IPs. Note that IPv6 is not yet supported for Pod IPs.
|
||||||
|
|
||||||
- Various approaches:
|
- Various approaches:
|
||||||
- GCE: each project has its own `10.0.0.0/8`. Carve off a `/16` for each
|
- GCE: each project has its own `10.0.0.0/8`. Carve off a `/16` for each
|
||||||
@@ -90,10 +103,8 @@ You need to select an address range for the Pod IPs.
|
|||||||
Each node gets a further subdivision of this space.
|
Each node gets a further subdivision of this space.
|
||||||
- AWS: use one VPC for whole organization, carve off a chunk for each
|
- AWS: use one VPC for whole organization, carve off a chunk for each
|
||||||
cluster, or use different VPC for different clusters.
|
cluster, or use different VPC for different clusters.
|
||||||
- IPv6 is not supported yet.
|
|
||||||
- Allocate one CIDR subnet for each node's PodIPs, or a single large CIDR
|
- Allocate one CIDR subnet for each node's PodIPs, or a single large CIDR
|
||||||
from which smaller CIDRs are automatically allocated to each node (if nodes
|
from which smaller CIDRs are automatically allocated to each node.
|
||||||
are dynamically added).
|
|
||||||
- You need max-pods-per-node * max-number-of-nodes IPs in total. A `/24` per
|
- You need max-pods-per-node * max-number-of-nodes IPs in total. A `/24` per
|
||||||
node supports 254 pods per machine and is a common choice. If IPs are
|
node supports 254 pods per machine and is a common choice. If IPs are
|
||||||
scarce, a `/26` (62 pods per machine) or even a `/27` (30 pods) may be sufficient.
|
scarce, a `/26` (62 pods per machine) or even a `/27` (30 pods) may be sufficient.
|
||||||
@@ -116,6 +127,17 @@ Also, you need to pick a static IP for master node.
|
|||||||
- Open any firewalls to allow access to the apiserver ports 80 and/or 443.
|
- Open any firewalls to allow access to the apiserver ports 80 and/or 443.
|
||||||
- Enable ipv4 forwarding sysctl, `net.ipv4.ip_forward = 1`
|
- Enable ipv4 forwarding sysctl, `net.ipv4.ip_forward = 1`
|
||||||
|
|
||||||
|
#### Network Policy
|
||||||
|
|
||||||
|
Kubernetes enables the definition of fine-grained network policy between Pods
|
||||||
|
using the [NetworkPolicy](/docs/user-guide/networkpolicy) resource.
|
||||||
|
|
||||||
|
Not all networking providers support the Kubernetes NetworkPolicy features.
|
||||||
|
For clusters which choose to enable NetworkPolicy, the
|
||||||
|
[Calico policy controller addon](https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/calico-policy-controller)
|
||||||
|
can enforce the NetworkPolicy API on top of native cloud-provider networking,
|
||||||
|
Flannel, or Calico networking.
|
||||||
|
|
||||||
### Cluster Naming
|
### Cluster Naming
|
||||||
|
|
||||||
You should pick a name for your cluster. Pick a short name for each cluster
|
You should pick a name for your cluster. Pick a short name for each cluster
|
||||||
@@ -823,7 +845,27 @@ Notes for setting up each cluster service are given below:
|
|||||||
|
|
||||||
### Running validate-cluster
|
### Running validate-cluster
|
||||||
|
|
||||||
**TODO** explain how to use `cluster/validate-cluster.sh`
|
`cluster/validate-cluster.sh` is used by `cluster/kube-up.sh` to determine if
|
||||||
|
the cluster start succeeded.
|
||||||
|
|
||||||
|
Example usage and output:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
KUBECTL_PATH=$(which kubectl) NUM_NODES=3 KUBERNETES_PROVIDER=local cluster/validate-cluster.sh
|
||||||
|
Found 3 node(s).
|
||||||
|
NAME STATUS AGE
|
||||||
|
node1.local Ready 1h
|
||||||
|
node2.local Ready 1h
|
||||||
|
node3.local Ready 1h
|
||||||
|
Validate output:
|
||||||
|
NAME STATUS MESSAGE ERROR
|
||||||
|
controller-manager Healthy ok
|
||||||
|
scheduler Healthy ok
|
||||||
|
etcd-1 Healthy {"health": "true"}
|
||||||
|
etcd-2 Healthy {"health": "true"}
|
||||||
|
etcd-0 Healthy {"health": "true"}
|
||||||
|
Cluster validation succeeded
|
||||||
|
```
|
||||||
|
|
||||||
### Inspect pods and services
|
### Inspect pods and services
|
||||||
|
|
||||||
|
|||||||
@@ -59,7 +59,7 @@ $ export ETCD_VERSION=2.2.0
|
|||||||
For users who want to bring up a cluster with k8s version v1.1.1, `controller manager` may fail to start
|
For users who want to bring up a cluster with k8s version v1.1.1, `controller manager` may fail to start
|
||||||
due to [a known issue](https://github.com/kubernetes/kubernetes/issues/17109). You could raise it
|
due to [a known issue](https://github.com/kubernetes/kubernetes/issues/17109). You could raise it
|
||||||
up manually by using following command on the remote master server. Note that
|
up manually by using following command on the remote master server. Note that
|
||||||
you should do this only after `api-server` is up. Moreover this issue is fixed in v1.1.2 and later.
|
you should do this only after `api-server` is up. Moreover, this issue is fixed in v1.1.2 and later.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
$ sudo service kube-controller-manager start
|
$ sudo service kube-controller-manager start
|
||||||
@@ -83,7 +83,7 @@ First configure the cluster information in cluster/ubuntu/config-default.sh, fol
|
|||||||
```shell
|
```shell
|
||||||
export nodes="vcap@10.10.103.250 vcap@10.10.103.162 vcap@10.10.103.223"
|
export nodes="vcap@10.10.103.250 vcap@10.10.103.162 vcap@10.10.103.223"
|
||||||
|
|
||||||
export role="ai i i"
|
export roles="ai i i"
|
||||||
|
|
||||||
export NUM_NODES=${NUM_NODES:-3}
|
export NUM_NODES=${NUM_NODES:-3}
|
||||||
|
|
||||||
@@ -95,7 +95,7 @@ export FLANNEL_NET=172.16.0.0/16
|
|||||||
The first variable `nodes` defines all your cluster nodes, master node comes first and
|
The first variable `nodes` defines all your cluster nodes, master node comes first and
|
||||||
separated with blank space like `<user_1@ip_1> <user_2@ip_2> <user_3@ip_3> `
|
separated with blank space like `<user_1@ip_1> <user_2@ip_2> <user_3@ip_3> `
|
||||||
|
|
||||||
Then the `role` variable defines the role of above machine in the same order, "ai" stands for machine
|
Then the `roles` variable defines the roles of above machine in the same order, "ai" stands for machine
|
||||||
acts as both master and node, "a" stands for master, "i" stands for node.
|
acts as both master and node, "a" stands for master, "i" stands for node.
|
||||||
|
|
||||||
The `NUM_NODES` variable defines the total number of nodes.
|
The `NUM_NODES` variable defines the total number of nodes.
|
||||||
|
|||||||
+1
-1
@@ -20,7 +20,7 @@ In the reference section, you can find reference documentation for Kubernetes AP
|
|||||||
|
|
||||||
## Glossary
|
## Glossary
|
||||||
|
|
||||||
Explore the glossary of essential Kubernetes concepts. Some good starting points are the entries for [Pods](/docs/user-guide/pods/), [Nodes](/docs/admin/node/), [Services](/docs/user-guide/services/), and [Replication Controllers](/docs/user-guide/replication-controller/).
|
Explore the glossary of essential Kubernetes concepts. Some good starting points are the entries for [Pods](/docs/user-guide/pods/), [Nodes](/docs/admin/node/), [Services](/docs/user-guide/services/), and [ReplicaSets](/docs/user-guide/replicasets/).
|
||||||
|
|
||||||
## Design Docs
|
## Design Docs
|
||||||
|
|
||||||
|
|||||||
@@ -100,13 +100,36 @@ with future high-availability support.
|
|||||||
|
|
||||||
### Programmatic access to the API
|
### Programmatic access to the API
|
||||||
|
|
||||||
There are [client libraries](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/client-libraries.md) for accessing the API
|
The Kubernetes project-supported Go client library is at [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go).
|
||||||
from several languages. The Kubernetes project-supported
|
|
||||||
[Go](http://releases.k8s.io/{{page.githubbranch}}/pkg/client/)
|
|
||||||
client library can use the same [kubeconfig file](/docs/user-guide/kubeconfig-file)
|
|
||||||
as the kubectl CLI does to locate and authenticate to the apiserver.
|
|
||||||
|
|
||||||
See documentation for other libraries for how they authenticate.
|
To use it,
|
||||||
|
* To get the library, run the following command: `go get k8s.io/client-go/<version number>/kubernetes` See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) to see which versions are supported.
|
||||||
|
* Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/1.4/pkg/api/v1"` is correct.
|
||||||
|
|
||||||
|
The Go client can use the same [kubeconfig file](/docs/user-guide/kubeconfig-file)
|
||||||
|
as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes/client-go/examples/out-of-cluster.go):
|
||||||
|
|
||||||
|
```golang
|
||||||
|
import (
|
||||||
|
"fmt"
|
||||||
|
"k8s.io/client-go/1.4/kubernetes"
|
||||||
|
"k8s.io/client-go/1.4/pkg/api/v1"
|
||||||
|
"k8s.io/client-go/1.4/tools/clientcmd"
|
||||||
|
)
|
||||||
|
...
|
||||||
|
// uses the current context in kubeconfig
|
||||||
|
config, _ := clientcmd.BuildConfigFromFlags("", "path to kubeconfig")
|
||||||
|
// creates the clientset
|
||||||
|
clientset, _:= kubernetes.NewForConfig(config)
|
||||||
|
// access the API to list pods
|
||||||
|
pods, _:= clientset.Core().Pods("").List(v1.ListOptions{})
|
||||||
|
fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
|
||||||
|
...
|
||||||
|
```
|
||||||
|
|
||||||
|
If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod).
|
||||||
|
|
||||||
|
There are [client libraries](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/client-libraries.md) for accessing the API from other languages. See documentation for other libraries for how they authenticate.
|
||||||
|
|
||||||
### Accessing the API from a Pod
|
### Accessing the API from a Pod
|
||||||
|
|
||||||
@@ -138,7 +161,7 @@ From within a pod the recommended ways to connect to API are:
|
|||||||
in any container of the pod can access it. See this [example of using kubectl proxy
|
in any container of the pod can access it. See this [example of using kubectl proxy
|
||||||
in a pod](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/kubectl-container/).
|
in a pod](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/kubectl-container/).
|
||||||
- use the Go client library, and create a client using the `client.NewInCluster()` factory.
|
- use the Go client library, and create a client using the `client.NewInCluster()` factory.
|
||||||
This handles locating and authenticating to the apiserver.
|
This handles locating and authenticating to the apiserver. [example](https://github.com/kubernetes/client-go/examples/in-cluster.go)
|
||||||
|
|
||||||
In each case, the credentials of the pod are used to communicate securely with the apiserver.
|
In each case, the credentials of the pod are used to communicate securely with the apiserver.
|
||||||
|
|
||||||
|
|||||||
@@ -122,11 +122,11 @@ runner (Docker or rkt).
|
|||||||
When using Docker:
|
When using Docker:
|
||||||
|
|
||||||
- The `spec.container[].resources.requests.cpu` is converted to its core value (potentially fractional),
|
- The `spec.container[].resources.requests.cpu` is converted to its core value (potentially fractional),
|
||||||
and multipled by 1024, and used as the value of the [`--cpu-shares`](
|
and multiplied by 1024, and used as the value of the [`--cpu-shares`](
|
||||||
https://docs.docker.com/reference/run/#runtime-constraints-on-resources) flag to the `docker run`
|
https://docs.docker.com/reference/run/#runtime-constraints-on-resources) flag to the `docker run`
|
||||||
command.
|
command.
|
||||||
- The `spec.container[].resources.limits.cpu` is converted to its millicore value,
|
- The `spec.container[].resources.limits.cpu` is converted to its millicore value,
|
||||||
multipled by 100000, and then divided by 1000, and used as the value of the [`--cpu-quota`](
|
multiplied by 100000, and then divided by 1000, and used as the value of the [`--cpu-quota`](
|
||||||
https://docs.docker.com/reference/run/#runtime-constraints-on-resources) flag to the `docker run`
|
https://docs.docker.com/reference/run/#runtime-constraints-on-resources) flag to the `docker run`
|
||||||
command. The [`--cpu-period`] flag is set to 100000 which represents the default 100ms period
|
command. The [`--cpu-period`] flag is set to 100000 which represents the default 100ms period
|
||||||
for measuring quota usage. The kubelet enforces cpu limits if it was started with the
|
for measuring quota usage. The kubelet enforces cpu limits if it was started with the
|
||||||
|
|||||||
@@ -10,7 +10,7 @@ assignees:
|
|||||||
|
|
||||||
## Configuration in Kubernetes
|
## Configuration in Kubernetes
|
||||||
|
|
||||||
In addition to the imperative-style commands, such as `kubectl run` and `kubectl expose`, described [elsewhere](/docs/user-guide/quick-start), Kubernetes supports declarative configuration. Often times, configuration files are preferable to imperative commands, since they can be checked into version control and changes to the files can be code reviewed, which is especially important for more complex configurations, producing a more robust, reliable and archival system.
|
In addition to the imperative-style commands, such as `kubectl run` and `kubectl expose`, described [elsewhere](/docs/user-guide/quick-start), Kubernetes supports declarative configuration. Oftentimes, configuration files are preferable to imperative commands, since they can be checked into version control and changes to the files can be code reviewed, which is especially important for more complex configurations, producing a more robust, reliable and archival system.
|
||||||
|
|
||||||
In the declarative style, all configuration is stored in YAML or JSON configuration files using Kubernetes's API resource schemas as the configuration schemas. `kubectl` can create, update, delete, and get API resources. The `apiVersion` (currently 'v1'?), resource `kind`, and resource `name` are used by `kubectl` to construct the appropriate API path to invoke for the specified operation.
|
In the declarative style, all configuration is stored in YAML or JSON configuration files using Kubernetes's API resource schemas as the configuration schemas. `kubectl` can create, update, delete, and get API resources. The `apiVersion` (currently 'v1'?), resource `kind`, and resource `name` are used by `kubectl` to construct the appropriate API path to invoke for the specified operation.
|
||||||
|
|
||||||
|
|||||||
@@ -78,7 +78,7 @@ nginx-deployment-2035384211-qqcnn 1/1 Running 0 18s app
|
|||||||
|
|
||||||
The created Replica Set will ensure that there are three nginx Pods at all times.
|
The created Replica Set will ensure that there are three nginx Pods at all times.
|
||||||
|
|
||||||
**Note:** You must specify appropriate selector and pod template labels of a Deployment (in this case, `app = nginx`), i.e. don't overlap with other controllers (including Deployments, Replica Sets, Replication Controllers, etc.) Kubernetes won't stop you from doing that, and if you end up with multiple controllers that have overlapping selectors, those controllers will fight with each others and won't behave correctly.
|
**Note:** You must specify appropriate selector and pod template labels of a Deployment (in this case, `app = nginx`), i.e. don't overlap with other controllers (including Deployments, Replica Sets, Replication Controllers, etc.) Kubernetes won't stop you from doing that, and if you end up with multiple controllers that have overlapping selectors, those controllers will fight with each other's and won't behave correctly.
|
||||||
|
|
||||||
## The Status of a Deployment
|
## The Status of a Deployment
|
||||||
|
|
||||||
@@ -503,7 +503,7 @@ number of Pods are less than the desired number.
|
|||||||
|
|
||||||
Note that you should not create other pods whose labels match this selector, either directly, via another Deployment or via another controller such as Replica Sets or Replication Controllers. Otherwise, the Deployment will think that those pods were created by it. Kubernetes will not stop you from doing this.
|
Note that you should not create other pods whose labels match this selector, either directly, via another Deployment or via another controller such as Replica Sets or Replication Controllers. Otherwise, the Deployment will think that those pods were created by it. Kubernetes will not stop you from doing this.
|
||||||
|
|
||||||
If you have multiple controllers that have overlapping selectors, the controllers will fight with each others and won't behave correctly.
|
If you have multiple controllers that have overlapping selectors, the controllers will fight with each other's and won't behave correctly.
|
||||||
|
|
||||||
### Strategy
|
### Strategy
|
||||||
|
|
||||||
|
|||||||
@@ -7,7 +7,7 @@ assignees:
|
|||||||
|
|
||||||
This guide explains how to use Kubernetes Federated Services to deploy
|
This guide explains how to use Kubernetes Federated Services to deploy
|
||||||
a common Service across multiple Kubernetes clusters. This makes it
|
a common Service across multiple Kubernetes clusters. This makes it
|
||||||
easy to achieve cross-cluster service discovery and availibility zone
|
easy to achieve cross-cluster service discovery and availability zone
|
||||||
fault tolerance for your Kubernetes applications.
|
fault tolerance for your Kubernetes applications.
|
||||||
|
|
||||||
|
|
||||||
@@ -42,7 +42,7 @@ Once created, the Federated Service automatically:
|
|||||||
|
|
||||||
1. creates matching Kubernetes Services in every cluster underlying your Cluster Federation,
|
1. creates matching Kubernetes Services in every cluster underlying your Cluster Federation,
|
||||||
2. monitors the health of those service "shards" (and the clusters in which they reside), and
|
2. monitors the health of those service "shards" (and the clusters in which they reside), and
|
||||||
3. manages a set of DNS records in a public DNS provder (like Google Cloud DNS, or AWS Route 53), thus ensuring that clients
|
3. manages a set of DNS records in a public DNS provider (like Google Cloud DNS, or AWS Route 53), thus ensuring that clients
|
||||||
of your federated service can seamlessly locate an appropriate healthy service endpoint at all times, even in the event of cluster,
|
of your federated service can seamlessly locate an appropriate healthy service endpoint at all times, even in the event of cluster,
|
||||||
availability zone or regional outages.
|
availability zone or regional outages.
|
||||||
|
|
||||||
@@ -200,7 +200,7 @@ nginx.mynamespace.myfederation.svc.asia-east1-b.example.com. CNAME 180 ngin
|
|||||||
nginx.mynamespace.myfederation.svc.asia-east1-c.example.com. A 180 130.211.56.221
|
nginx.mynamespace.myfederation.svc.asia-east1-c.example.com. A 180 130.211.56.221
|
||||||
nginx.mynamespace.myfederation.svc.asia-east1.example.com. A 180 130.211.57.243, 130.211.56.221
|
nginx.mynamespace.myfederation.svc.asia-east1.example.com. A 180 130.211.57.243, 130.211.56.221
|
||||||
nginx.mynamespace.myfederation.svc.europe-west1.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.example.com.
|
nginx.mynamespace.myfederation.svc.europe-west1.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.example.com.
|
||||||
nginx.mynamespace.myfederation.svc.europe-west1-d.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.europe-west1.example.com.
|
nginx.mynamespace.myfederation.svc.europe-west1-d.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.europe-west1.example.com.
|
||||||
... etc.
|
... etc.
|
||||||
```
|
```
|
||||||
|
|
||||||
@@ -224,7 +224,7 @@ due to caching by intermediate DNS servers.
|
|||||||
|
|
||||||
### Some notes about the above example
|
### Some notes about the above example
|
||||||
|
|
||||||
1. Notice that there is a normal ('A') record for each service shard that has at least one healthy backend endpoint. For example in us-central1-a, 104.197.247.191 is the external IP address of the service shard in that zone, and in asia-east1-a the address is 130.211.56.221.
|
1. Notice that there is a normal ('A') record for each service shard that has at least one healthy backend endpoint. For example, in us-central1-a, 104.197.247.191 is the external IP address of the service shard in that zone, and in asia-east1-a the address is 130.211.56.221.
|
||||||
2. Similarly, there are regional 'A' records which include all healthy shards in that region. For example, 'us-central1'. These regional records are useful for clients which do not have a particular zone preference, and as a building block for the automated locality and failover mechanism described below.
|
2. Similarly, there are regional 'A' records which include all healthy shards in that region. For example, 'us-central1'. These regional records are useful for clients which do not have a particular zone preference, and as a building block for the automated locality and failover mechanism described below.
|
||||||
2. For zones where there are currently no healthy backend endpoints, a CNAME ('Canonical Name') record is used to alias (automatically redirect) those queries to the next closest healthy zone. In the example, the service shard in us-central1-f currently has no healthy backend endpoints (i.e. Pods), so a CNAME record has been created to automatically redirect queries to other shards in that region (us-central1 in this case).
|
2. For zones where there are currently no healthy backend endpoints, a CNAME ('Canonical Name') record is used to alias (automatically redirect) those queries to the next closest healthy zone. In the example, the service shard in us-central1-f currently has no healthy backend endpoints (i.e. Pods), so a CNAME record has been created to automatically redirect queries to other shards in that region (us-central1 in this case).
|
||||||
3. Similarly, if no healthy shards exist in the enclosing region, the search progresses further afield. In the europe-west1-d availability zone, there are no healthy backends, so queries are redirected to the broader europe-west1 region (which also has no healthy backends), and onward to the global set of healthy addresses (' nginx.mynamespace.myfederation.svc.example.com.')
|
3. Similarly, if no healthy shards exist in the enclosing region, the search progresses further afield. In the europe-west1-d availability zone, there are no healthy backends, so queries are redirected to the broader europe-west1 region (which also has no healthy backends), and onward to the global set of healthy addresses (' nginx.mynamespace.myfederation.svc.example.com.')
|
||||||
@@ -295,7 +295,7 @@ availability zones and regions other than the ones local to a Pod by
|
|||||||
specifying the appropriate DNS names explicitly, and not relying on
|
specifying the appropriate DNS names explicitly, and not relying on
|
||||||
automatic DNS expansion. For example,
|
automatic DNS expansion. For example,
|
||||||
"nginx.mynamespace.myfederation.svc.europe-west1.example.com" will
|
"nginx.mynamespace.myfederation.svc.europe-west1.example.com" will
|
||||||
resolve to all of the currently healthy service shards in Europe, even
|
resolve to all of the currently healthy service shards in europe, even
|
||||||
if the Pod issuing the lookup is located in the U.S., and irrespective
|
if the Pod issuing the lookup is located in the U.S., and irrespective
|
||||||
of whether or not there are healthy shards of the service in the U.S.
|
of whether or not there are healthy shards of the service in the U.S.
|
||||||
This is useful for remote monitoring and other similar applications.
|
This is useful for remote monitoring and other similar applications.
|
||||||
@@ -366,7 +366,7 @@ Check that:
|
|||||||
1. Your federation name, DNS provider, DNS domain name are configured correctly. Consult the [federation admin guide](/docs/admin/federation/) or [tutorial](https://github.com/kelseyhightower/kubernetes-cluster-federation) to learn
|
1. Your federation name, DNS provider, DNS domain name are configured correctly. Consult the [federation admin guide](/docs/admin/federation/) or [tutorial](https://github.com/kelseyhightower/kubernetes-cluster-federation) to learn
|
||||||
how to configure your Cluster Federation system's DNS provider (or have your cluster administrator do this for you).
|
how to configure your Cluster Federation system's DNS provider (or have your cluster administrator do this for you).
|
||||||
2. Confirm that the Cluster Federation's service-controller is successfully connecting to and authenticating against your selected DNS provider (look for `service-controller` errors or successes in the output of `kubectl logs federation-controller-manager --namespace federation`)
|
2. Confirm that the Cluster Federation's service-controller is successfully connecting to and authenticating against your selected DNS provider (look for `service-controller` errors or successes in the output of `kubectl logs federation-controller-manager --namespace federation`)
|
||||||
3. Confirm that the Cluster Federation's service-controller is successfully creating DNS records in your DNS provider (or outputting errors in it's logs explaining in more detail what's failing).
|
3. Confirm that the Cluster Federation's service-controller is successfully creating DNS records in your DNS provider (or outputting errors in its logs explaining in more detail what's failing).
|
||||||
|
|
||||||
#### Matching DNS records are created in my DNS provider, but clients are unable to resolve against those names
|
#### Matching DNS records are created in my DNS provider, but clients are unable to resolve against those names
|
||||||
Check that:
|
Check that:
|
||||||
|
|||||||
@@ -120,13 +120,14 @@ all running pods. Example:
|
|||||||
alpha/target.custom-metrics.podautoscaler.kubernetes.io: '{"items":[{"name":"qps", "value": "10"}]}'
|
alpha/target.custom-metrics.podautoscaler.kubernetes.io: '{"items":[{"name":"qps", "value": "10"}]}'
|
||||||
```
|
```
|
||||||
|
|
||||||
In this case if there are 4 pods running and each of them reports qps metric to be equal to 15 HPA will start 2 additional pods so there will be 6 pods in total. If there are multiple metrics passed in the annotation or CPU is configured as well then HPA will use the biggest
|
In this case, if there are four pods running and each pod reports a QPS metric of 15 or higher, horizontal pod autoscaling will start two additional pods (for a total of six pods running).
|
||||||
number of replicas that comes from the calculations.
|
|
||||||
|
If you specify multiple metrics in your annotation or if you set a target CPU utilization, horizontal pod autoscaling will scale to according to the metric that requires the highest number of replicas.
|
||||||
|
|
||||||
|
If you do not specify a target for CPU utilization, Kubernetes defaults to an 80% utilization threshold for horizontal pod autoscaling.
|
||||||
|
|
||||||
|
If you want to ensure that horizontal pod autoscaling calculates the number of required replicas based only on custom metrics, you should set the CPU utilization target to a very large value (such as 100000%). As this level of CPU utilization isn't possible, horizontal pod autoscaling will calculate based only on the custom metrics (and min/max limits).
|
||||||
|
|
||||||
At this moment even if target CPU utilization is not specified a default of 80% will be used.
|
|
||||||
To calculate number of desired replicas based only on custom metrics CPU utilization
|
|
||||||
target should be set to a very large value (e.g. 100000%). Then CPU-related logic
|
|
||||||
will want only 1 replica, leaving the decision about higher replica count to cusom metrics (and min/max limits).
|
|
||||||
|
|
||||||
## Further reading
|
## Further reading
|
||||||
|
|
||||||
|
|||||||
@@ -44,13 +44,7 @@ It can be configured to give services externally-reachable urls, load balance tr
|
|||||||
|
|
||||||
Before you start using the Ingress resource, there are a few things you should understand. The Ingress is a beta resource, not available in any Kubernetes release prior to 1.1. You need an Ingress controller to satisfy an Ingress, simply creating the resource will have no effect.
|
Before you start using the Ingress resource, there are a few things you should understand. The Ingress is a beta resource, not available in any Kubernetes release prior to 1.1. You need an Ingress controller to satisfy an Ingress, simply creating the resource will have no effect.
|
||||||
|
|
||||||
On GCE/GKE there should be a [L7 cluster addon](https://github.com/kubernetes/contrib/blob/master/ingress/controllers/gce/README.md), deployed into the `kube-system` namespace:
|
GCE/GKE deploys an ingress controller on the master. You can deploy any number of custom ingress controllers in a pod. You must annotate each ingress with the appropriate class, as indicated [here](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx#running-multiple-ingress-controllers) and [here](https://github.com/kubernetes/contrib/blob/master/ingress/controllers/gce/BETA_LIMITATIONS.md#disabling-glbc).
|
||||||
|
|
||||||
```shell
|
|
||||||
$ kubectl get pods --namespace=kube-system -l k8s-app=glbc
|
|
||||||
NAME READY STATUS RESTARTS AGE
|
|
||||||
l7-lb-controller-v0.6.0-chnan 2/2 Running 0 1d
|
|
||||||
```
|
|
||||||
|
|
||||||
Make sure you review the [beta limitations](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/gce/BETA_LIMITATIONS.md) of this controller. In environments other than GCE/GKE, you need to [deploy a controller](https://github.com/kubernetes/contrib/tree/master/ingress/controllers) as a pod.
|
Make sure you review the [beta limitations](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/gce/BETA_LIMITATIONS.md) of this controller. In environments other than GCE/GKE, you need to [deploy a controller](https://github.com/kubernetes/contrib/tree/master/ingress/controllers) as a pod.
|
||||||
|
|
||||||
|
|||||||
@@ -167,7 +167,7 @@ parallelism, for a variety or reasons:
|
|||||||
A Container in a Pod may fail for a number of reasons, such as because the process in it exited with
|
A Container in a Pod may fail for a number of reasons, such as because the process in it exited with
|
||||||
a non-zero exit code, or the Container was killed for exceeding a memory limit, etc. If this
|
a non-zero exit code, or the Container was killed for exceeding a memory limit, etc. If this
|
||||||
happens, and the `.spec.template.containers[].restartPolicy = "OnFailure"`, then the Pod stays
|
happens, and the `.spec.template.containers[].restartPolicy = "OnFailure"`, then the Pod stays
|
||||||
on the node, but the Container is re-run. Therefore, your program needs to handle the the case when it is
|
on the node, but the Container is re-run. Therefore, your program needs to handle the case when it is
|
||||||
restarted locally, or else specify `.spec.template.containers[].restartPolicy = "Never"`.
|
restarted locally, or else specify `.spec.template.containers[].restartPolicy = "Never"`.
|
||||||
See [pods-states](/docs/user-guide/pod-states) for more information on `restartPolicy`.
|
See [pods-states](/docs/user-guide/pod-states) for more information on `restartPolicy`.
|
||||||
|
|
||||||
|
|||||||
@@ -54,7 +54,7 @@ job-banana.yaml
|
|||||||
job-cherry.yaml
|
job-cherry.yaml
|
||||||
```
|
```
|
||||||
|
|
||||||
Here, we used `sed` to replace the string `$ITEM` with the the loop variable.
|
Here, we used `sed` to replace the string `$ITEM` with the loop variable.
|
||||||
You could use any type of template language (jinja2, erb) or write a program
|
You could use any type of template language (jinja2, erb) or write a program
|
||||||
to generate the Job objects.
|
to generate the Job objects.
|
||||||
|
|
||||||
|
|||||||
@@ -122,8 +122,7 @@ root@temp-loe07:/#
|
|||||||
```
|
```
|
||||||
|
|
||||||
In the last command, the `amqp-consume` tool takes one message (`-c 1`)
|
In the last command, the `amqp-consume` tool takes one message (`-c 1`)
|
||||||
from the queue, and passes that message to the standard input of an
|
from the queue, and passes that message to the standard input of an arbitrary command. In this case, the program `cat` is just printing
|
||||||
an arbitrary command. In this case, the program `cat` is just printing
|
|
||||||
out what it gets on the standard input, and the echo is just to add a carriage
|
out what it gets on the standard input, and the echo is just to add a carriage
|
||||||
return so the example is readable.
|
return so the example is readable.
|
||||||
|
|
||||||
@@ -169,7 +168,7 @@ example program:
|
|||||||
|
|
||||||
{% include code.html language="python" file="worker.py" ghlink="/docs/user-guide/job/work-queue-1/worker.py" %}
|
{% include code.html language="python" file="worker.py" ghlink="/docs/user-guide/job/work-queue-1/worker.py" %}
|
||||||
|
|
||||||
Now, build an an image. If you are working in the source
|
Now, build an image. If you are working in the source
|
||||||
tree, then change directory to `examples/job/work-queue-1`.
|
tree, then change directory to `examples/job/work-queue-1`.
|
||||||
Otherwise, make a temporary directory, change to it,
|
Otherwise, make a temporary directory, change to it,
|
||||||
download the [Dockerfile](Dockerfile?raw=true),
|
download the [Dockerfile](Dockerfile?raw=true),
|
||||||
@@ -275,7 +274,7 @@ not all items will be processed.
|
|||||||
If the number of completions is set to more than the number of items in the queue,
|
If the number of completions is set to more than the number of items in the queue,
|
||||||
then the Job will not appear to be completed, even though all items in the queue
|
then the Job will not appear to be completed, even though all items in the queue
|
||||||
have been processed. It will start additional pods which will block waiting
|
have been processed. It will start additional pods which will block waiting
|
||||||
for a mesage.
|
for a message.
|
||||||
|
|
||||||
There is an unlikely race with this pattern. If the container is killed in between the time
|
There is an unlikely race with this pattern. If the container is killed in between the time
|
||||||
that the message is acknowledged by the amqp-consume command and the time that the container
|
that the message is acknowledged by the amqp-consume command and the time that the container
|
||||||
|
|||||||
@@ -31,7 +31,7 @@ Here is an overview of the steps in this example:
|
|||||||
|
|
||||||
For this example, for simplicitly, we will start a single instance of Redis.
|
For this example, for simplicitly, we will start a single instance of Redis.
|
||||||
See the [Redis Example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/redis/README.md) for an example
|
See the [Redis Example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/redis/README.md) for an example
|
||||||
of deploying Redis scaleably and redundantly.
|
of deploying Redis scalably and redundantly.
|
||||||
|
|
||||||
Start a temporary Pod running Redis and a service so we can find it.
|
Start a temporary Pod running Redis and a service so we can find it.
|
||||||
|
|
||||||
|
|||||||
@@ -16,7 +16,7 @@ So in order to easily switch between multiple clusters, for multiple users, a ku
|
|||||||
|
|
||||||
This file contains a series of authentication mechanisms and cluster connection information associated with nicknames. It also introduces the concept of a tuple of authentication information (user) and cluster connection information called a context that is also associated with a nickname.
|
This file contains a series of authentication mechanisms and cluster connection information associated with nicknames. It also introduces the concept of a tuple of authentication information (user) and cluster connection information called a context that is also associated with a nickname.
|
||||||
|
|
||||||
Multiple kubeconfig files are allowed, if specified explicitly. At runtime they are loaded and merged together along with override options specified from the command line (see [rules](#loading-and-merging) below).
|
Multiple kubeconfig files are allowed, if specified explicitly. At runtime they are loaded and merged along with override options specified from the command line (see [rules](#loading-and-merging) below).
|
||||||
|
|
||||||
## Related discussion
|
## Related discussion
|
||||||
|
|
||||||
@@ -307,8 +307,8 @@ $ kubectl config use-context federal-context
|
|||||||
|
|
||||||
So, tying this all together, a quick start to creating your own kubeconfig file:
|
So, tying this all together, a quick start to creating your own kubeconfig file:
|
||||||
|
|
||||||
- Take a good look and understand how you're api-server is being launched: You need to know YOUR security requirements and policies before you can design a kubeconfig file for convenient authentication.
|
- Take a good look and understand how your api-server is being launched: You need to know YOUR security requirements and policies before you can design a kubeconfig file for convenient authentication.
|
||||||
|
|
||||||
- Replace the snippet above with information for your cluster's api-server endpoint.
|
- Replace the snippet above with information for your cluster's api-server endpoint.
|
||||||
|
|
||||||
- Make sure your api-server is launched in such a way that at least one user (i.e. green-user) credentials are provided to it. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details.
|
- Make sure your api-server is launched in such a way that at least one user (i.e. green-user) credentials are provided to it. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details.
|
||||||
|
|||||||
@@ -85,7 +85,7 @@ $ kubectl describe pods <rc-name> # Lists pods created by <rc-name
|
|||||||
$ kubectl get services --sort-by=.metadata.name
|
$ kubectl get services --sort-by=.metadata.name
|
||||||
|
|
||||||
# List pods Sorted by Restart Count
|
# List pods Sorted by Restart Count
|
||||||
$ kubectl get pods --sort-by=.status.containerStatuses[0].restartCount
|
$ kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
|
||||||
|
|
||||||
# Get the version label of all pods with label app=cassandra
|
# Get the version label of all pods with label app=cassandra
|
||||||
$ kubectl get pods --selector=app=cassandra rc -o 'jsonpath={.items[*].metadata.labels.version}'
|
$ kubectl get pods --selector=app=cassandra rc -o 'jsonpath={.items[*].metadata.labels.version}'
|
||||||
@@ -95,12 +95,13 @@ $ kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="External
|
|||||||
|
|
||||||
# List Names of Pods that belong to Particular RC
|
# List Names of Pods that belong to Particular RC
|
||||||
# "jq" command useful for transformations that are too complex for jsonpath
|
# "jq" command useful for transformations that are too complex for jsonpath
|
||||||
$ sel=$(./kubectl get rc <rc-name> --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')
|
$ sel=$(kubectl get rc <rc-name> --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')
|
||||||
$ sel=${sel%?} # Remove trailing comma
|
$ sel=${sel%?} # Remove trailing comma
|
||||||
$ pods=$(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})`
|
$ pods=$(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})
|
||||||
|
$ echo $pods
|
||||||
|
|
||||||
# Check which nodes are ready
|
# Check which nodes are ready
|
||||||
$ kubectl get nodes -o jsonpath='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}'| tr ';' "\n" | grep "Ready=True"
|
$ kubectl get nodes -o jsonpath='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}'| tr ';' "\n" | grep "Ready=True"
|
||||||
```
|
```
|
||||||
|
|
||||||
## Modifying and Deleting Resources
|
## Modifying and Deleting Resources
|
||||||
@@ -122,6 +123,6 @@ $ kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interacti
|
|||||||
$ kubectl attach <podname> -i # Attach to Running Container
|
$ kubectl attach <podname> -i # Attach to Running Container
|
||||||
$ kubectl port-forward <podname> <local-and-remote-port> # Forward port of Pod to your local machine
|
$ kubectl port-forward <podname> <local-and-remote-port> # Forward port of Pod to your local machine
|
||||||
$ kubectl port-forward <servicename> <port> # Forward port to service
|
$ kubectl port-forward <servicename> <port> # Forward port to service
|
||||||
$ kubectl exec <pod-name> -- ls / # Run command in existing pod (1 container case)
|
$ kubectl exec <pod-name> -- ls / # Run command in existing pod (1 container case)
|
||||||
$ kubectl exec <pod-name> -c <container-name> -- ls / # Run command in existing pod (multi-container case)
|
$ kubectl exec <pod-name> -c <container-name> -- ls / # Run command in existing pod (multi-container case)
|
||||||
```
|
```
|
||||||
|
|||||||
@@ -266,7 +266,7 @@ $ kubectl exec -ti <pod-name> /bin/bash
|
|||||||
// Return a snapshot of the logs from pod <pod-name>.
|
// Return a snapshot of the logs from pod <pod-name>.
|
||||||
$ kubectl logs <pod-name>
|
$ kubectl logs <pod-name>
|
||||||
|
|
||||||
// Start streaming the logs from pod <pod-name>. This is similiar to the 'tail -f' Linux command.
|
// Start streaming the logs from pod <pod-name>. This is similar to the 'tail -f' Linux command.
|
||||||
$ kubectl logs -f <pod-name>
|
$ kubectl logs -f <pod-name>
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|||||||
@@ -20,10 +20,10 @@ kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MA
|
|||||||
### Examples
|
### Examples
|
||||||
|
|
||||||
```
|
```
|
||||||
# Auto scale a deployment "foo", with the number of pods between 2 to 10, no target CPU utilization specfied so a default autoscaling policy will be used:
|
# Auto scale a deployment "foo", with the number of pods between 2 and 10, no target CPU utilization specfied so a default autoscaling policy will be used:
|
||||||
kubectl autoscale deployment foo --min=2 --max=10
|
kubectl autoscale deployment foo --min=2 --max=10
|
||||||
|
|
||||||
# Auto scale a replication controller "foo", with the number of pods between 1 to 5, target CPU utilization at 80%:
|
# Auto scale a replication controller "foo", with the number of pods between 1 and 5, target CPU utilization at 80%:
|
||||||
kubectl autoscale rc foo --max=5 --cpu-percent=80
|
kubectl autoscale rc foo --max=5 --cpu-percent=80
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|||||||
@@ -12,7 +12,7 @@ config modifies kubeconfig files using subcommands like "kubectl config set curr
|
|||||||
|
|
||||||
The loading order follows these rules:
|
The loading order follows these rules:
|
||||||
1. If the --kubeconfig flag is set, then only that file is loaded. The flag may only be set once and no merging takes place.
|
1. If the --kubeconfig flag is set, then only that file is loaded. The flag may only be set once and no merging takes place.
|
||||||
2. If $KUBECONFIG environment variable is set, then it is used a list of paths (normal path delimitting rules for your system). These paths are merged together. When a value is modified, it is modified in the file that defines the stanza. When a value is created, it is created in the first file that exists. If no files in the chain exist, then it creates the last file in the list.
|
2. If $KUBECONFIG environment variable is set, then it is used a list of paths (normal path delimitting rules for your system). These paths are merged. When a value is modified, it is modified in the file that defines the stanza. When a value is created, it is created in the first file that exists. If no files in the chain exist, then it creates the last file in the list.
|
||||||
3. Otherwise, ${HOME}/.kube/config is used and no merging takes place.
|
3. Otherwise, ${HOME}/.kube/config is used and no merging takes place.
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
@@ -12,7 +12,7 @@ Sets a cluster entry in kubeconfig.
|
|||||||
Specifying a name that already exists will merge new fields on top of existing values for those fields.
|
Specifying a name that already exists will merge new fields on top of existing values for those fields.
|
||||||
|
|
||||||
```
|
```
|
||||||
kubectl config set-cluster NAME [--server=server] [--certificate-authority=path/to/certficate/authority] [--insecure-skip-tls-verify=true]
|
kubectl config set-cluster NAME [--server=server] [--certificate-authority=path/to/certificate/authority] [--insecure-skip-tls-verify=true]
|
||||||
```
|
```
|
||||||
|
|
||||||
### Examples
|
### Examples
|
||||||
|
|||||||
@@ -9,7 +9,7 @@ Sets an individual value in a kubeconfig file
|
|||||||
|
|
||||||
|
|
||||||
Sets an individual value in a kubeconfig file
|
Sets an individual value in a kubeconfig file
|
||||||
PROPERTY_NAME is a dot delimited name where each token represents either a attribute name or a map key. Map keys may not contain dots.
|
PROPERTY_NAME is a dot delimited name where each token represents either an attribute name or a map key. Map keys may not contain dots.
|
||||||
PROPERTY_VALUE is the new value you wish to set. Binary fields such as 'certificate-authority-data' expect a base64 encoded string unless the --set-raw-bytes flag is used.
|
PROPERTY_VALUE is the new value you wish to set. Binary fields such as 'certificate-authority-data' expect a base64 encoded string unless the --set-raw-bytes flag is used.
|
||||||
|
|
||||||
```
|
```
|
||||||
|
|||||||
@@ -9,7 +9,7 @@ Unsets an individual value in a kubeconfig file
|
|||||||
|
|
||||||
|
|
||||||
Unsets an individual value in a kubeconfig file
|
Unsets an individual value in a kubeconfig file
|
||||||
PROPERTY_NAME is a dot delimited name where each token represents either a attribute name or a map key. Map keys may not contain dots.
|
PROPERTY_NAME is a dot delimited name where each token represents either an attribute name or a map key. Map keys may not contain dots.
|
||||||
|
|
||||||
```
|
```
|
||||||
kubectl config unset PROPERTY_NAME
|
kubectl config unset PROPERTY_NAME
|
||||||
|
|||||||
@@ -29,8 +29,8 @@ kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
|
|||||||
### Options
|
### Options
|
||||||
|
|
||||||
```
|
```
|
||||||
--flatten[=false]: flatten the resulting kubeconfig file into self contained output (useful for creating portable kubeconfig files)
|
--flatten[=false]: flatten the resulting kubeconfig file into self-contained output (useful for creating portable kubeconfig files)
|
||||||
--merge[=true]: merge together the full hierarchy of kubeconfig files
|
--merge[=true]: merge the full hierarchy of kubeconfig files
|
||||||
--minify[=false]: remove all information not used by current-context from the output
|
--minify[=false]: remove all information not used by current-context from the output
|
||||||
--no-headers[=false]: When using the default output, don't print headers.
|
--no-headers[=false]: When using the default output, don't print headers.
|
||||||
-o, --output="": Output format. One of: json|yaml|wide|name|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=... See golang template [http://golang.org/pkg/text/template/#pkg-overview] and jsonpath template [http://releases.k8s.io/release-1.3/docs/user-guide/jsonpath.md].
|
-o, --output="": Output format. One of: json|yaml|wide|name|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=... See golang template [http://golang.org/pkg/text/template/#pkg-overview] and jsonpath template [http://releases.k8s.io/release-1.3/docs/user-guide/jsonpath.md].
|
||||||
|
|||||||
@@ -11,13 +11,13 @@ Drain node in preparation for maintenance
|
|||||||
Drain node in preparation for maintenance.
|
Drain node in preparation for maintenance.
|
||||||
|
|
||||||
The given node will be marked unschedulable to prevent new pods from arriving.
|
The given node will be marked unschedulable to prevent new pods from arriving.
|
||||||
Then drain deletes all pods except mirror pods (which cannot be deleted through
|
The `drain` deletes all pods except mirror pods (which cannot be deleted through
|
||||||
the API server). If there are DaemonSet-managed pods, drain will not proceed
|
the API server). If there are DaemonSet-managed pods, drain will not proceed
|
||||||
without --ignore-daemonsets, and regardless it will not delete any
|
without --ignore-daemonsets, and regardless it will not delete any
|
||||||
DaemonSet-managed pods, because those pods would be immediately replaced by the
|
DaemonSet-managed pods, because those pods would be immediately replaced by the
|
||||||
DaemonSet controller, which ignores unschedulable markings. If there are any
|
DaemonSet controller, which ignores unschedulable markings. If there are any
|
||||||
pods that are neither mirror pods nor managed--by ReplicationController,
|
pods that are neither mirror pods nor managed by ReplicationController,
|
||||||
ReplicaSet, DaemonSet or Job--, then drain will not delete any pods unless you
|
ReplicaSet, DaemonSet or Job, then drain will not delete any pods unless you
|
||||||
use --force.
|
use --force.
|
||||||
|
|
||||||
When you are ready to put the node back into service, use kubectl uncordon, which
|
When you are ready to put the node back into service, use kubectl uncordon, which
|
||||||
|
|||||||
@@ -59,7 +59,7 @@ kubectl expose deployment nginx --port=80 --target-port=8000
|
|||||||
-f, --filename=[]: Filename, directory, or URL to a file identifying the resource to expose a service
|
-f, --filename=[]: Filename, directory, or URL to a file identifying the resource to expose a service
|
||||||
--generator="service/v2": The name of the API generator to use. There are 2 generators: 'service/v1' and 'service/v2'. The only difference between them is that service port in v1 is named 'default', while it is left unnamed in v2. Default is 'service/v2'.
|
--generator="service/v2": The name of the API generator to use. There are 2 generators: 'service/v1' and 'service/v2'. The only difference between them is that service port in v1 is named 'default', while it is left unnamed in v2. Default is 'service/v2'.
|
||||||
-l, --labels="": Labels to apply to the service created by this call.
|
-l, --labels="": Labels to apply to the service created by this call.
|
||||||
--load-balancer-ip="": IP to assign to to the Load Balancer. If empty, an ephemeral IP will be created and used (cloud-provider specific).
|
--load-balancer-ip="": IP to assign to the Load Balancer. If empty, an ephemeral IP will be created and used (cloud-provider specific).
|
||||||
--name="": The name for the newly created object.
|
--name="": The name for the newly created object.
|
||||||
--no-headers[=false]: When using the default output, don't print headers.
|
--no-headers[=false]: When using the default output, don't print headers.
|
||||||
-o, --output="": Output format. One of: json|yaml|wide|name|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=... See golang template [http://golang.org/pkg/text/template/#pkg-overview] and jsonpath template [http://releases.k8s.io/release-1.3/docs/user-guide/jsonpath.md].
|
-o, --output="": Output format. One of: json|yaml|wide|name|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=... See golang template [http://golang.org/pkg/text/template/#pkg-overview] and jsonpath template [http://releases.k8s.io/release-1.3/docs/user-guide/jsonpath.md].
|
||||||
|
|||||||
@@ -104,7 +104,7 @@ LIST and WATCH operations may specify label selectors to filter the sets of obje
|
|||||||
* _equality-based_ requirements: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
|
* _equality-based_ requirements: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
|
||||||
* _set-based_ requirements: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
|
* _set-based_ requirements: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
|
||||||
|
|
||||||
Both label selector styles can be used to list or watch resources via a REST client. For example targeting `apiserver` with `kubectl` and using _equality-based_ one may write:
|
Both label selector styles can be used to list or watch resources via a REST client. For example, targeting `apiserver` with `kubectl` and using _equality-based_ one may write:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
$ kubectl get pods -l environment=production,tier=frontend
|
$ kubectl get pods -l environment=production,tier=frontend
|
||||||
|
|||||||
@@ -90,7 +90,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
|
|||||||
## Not All Objects are in a Namespace
|
## Not All Objects are in a Namespace
|
||||||
|
|
||||||
Most kubernetes resources (e.g. pods, services, replication controllers, and others) are
|
Most kubernetes resources (e.g. pods, services, replication controllers, and others) are
|
||||||
in a some namespace. However namespace resources are not themselves in a namespace.
|
in some namespace. However namespace resources are not themselves in a namespace.
|
||||||
And, low-level resources, such as [nodes](/docs/admin/node) and
|
And low-level resources, such as [nodes](/docs/admin/node) and
|
||||||
persistentVolumes, are not in any namespace. Events are an exception: they may or may not
|
persistentVolumes, are not in any namespace. Events are an exception: they may or may not
|
||||||
have a namespace, depending on the object the event is about.
|
have a namespace, depending on the object the event is about.
|
||||||
|
|||||||
@@ -25,7 +25,7 @@ If this fails with an "invalid command" error, you're likely using an older vers
|
|||||||
|
|
||||||
Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/identifiers.md)), meaning that they are not allowed to contain any upper-case letters.
|
Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/identifiers.md)), meaning that they are not allowed to contain any upper-case letters.
|
||||||
|
|
||||||
You can verify that it worked by re-running `kubectl get nodes` and checking that the node now has a label.
|
You can verify that it worked by re-running `kubectl get nodes --show-labels` and checking that the node now has a label.
|
||||||
|
|
||||||
### Step Two: Add a nodeSelector field to your pod configuration
|
### Step Two: Add a nodeSelector field to your pod configuration
|
||||||
|
|
||||||
|
|||||||
@@ -20,21 +20,6 @@ A `PersistentVolume` (PV) is a piece of networked storage in the cluster that ha
|
|||||||
|
|
||||||
A `PersistentVolumeClaim` (PVC) is a request for storage by a user. It is similar to a pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g, can be mounted once read/write or many times read-only).
|
A `PersistentVolumeClaim` (PVC) is a request for storage by a user. It is similar to a pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g, can be mounted once read/write or many times read-only).
|
||||||
|
|
||||||
While `PersistentVolumeClaims` allow a user to consume abstract storage
|
|
||||||
resources, it is common that users need `PersistentVolumes` with varying
|
|
||||||
properties, such as performance, for different problems. Cluster administrators
|
|
||||||
need to be able to offer a variety of `PersistentVolumes` that differ in more
|
|
||||||
ways than just size and access modes, without exposing users to the details of
|
|
||||||
how those volumes are implemented. For these needs there is the `StorageClass`
|
|
||||||
resource.
|
|
||||||
|
|
||||||
A `StorageClass` provides a way for administrators to describe the "classes" of
|
|
||||||
storage they offer. Different classes might map to quality-of-service levels,
|
|
||||||
or to backup policies, or to arbitrary policies determined by the cluster
|
|
||||||
administrators. Kubernetes itself is unopinionated about what classes
|
|
||||||
represent. This concept is sometimes called "profiles" in other storage
|
|
||||||
systems.
|
|
||||||
|
|
||||||
Please see the [detailed walkthrough with working examples](/docs/user-guide/persistent-volumes/walkthrough/).
|
Please see the [detailed walkthrough with working examples](/docs/user-guide/persistent-volumes/walkthrough/).
|
||||||
|
|
||||||
|
|
||||||
@@ -44,17 +29,11 @@ PVs are resources in the cluster. PVCs are requests for those resources and als
|
|||||||
|
|
||||||
### Provisioning
|
### Provisioning
|
||||||
|
|
||||||
There are two ways PVs may be provisioned: statically or dynamically.
|
A cluster administrator will create a number of PVs. They carry the details of the real storage which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.
|
||||||
|
|
||||||
#### Static
|
|
||||||
A cluster administrator creates a number of PVs. They carry the details of the real storage which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.
|
|
||||||
|
|
||||||
#### Dynamic
|
|
||||||
When none of the static PVs the administrator created matches a user's `PersistentVolumeClaim`, the cluster may try to dynamically provision a volume specially for the PVC. This provisioning is based on `StorageClasses`: the PVC must request a class and the administrator must have created and configured that class in order for dynamic provisioning to occur. Claims that request the class `""` effectively disable dynamic provisioning for themselves.
|
|
||||||
|
|
||||||
### Binding
|
### Binding
|
||||||
|
|
||||||
A user creates, or has already created in the case of dynamic provisioning, a `PersistentVolumeClaim` with a specific amount of storage requested and with certain access modes. A control loop in the master watches for new PVCs, finds a matching PV (if possible), and binds them together. If a PV was dynamically provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise, the user will always get at least what they asked for, but the volume may be in excess of what was requested. Once bound, `PersistentVolumeClaim` binds are exclusive, regardless of the mode used to bind them.
|
A user creates a `PersistentVolumeClaim` with a specific amount of storage requested and with certain access modes. A control loop in the master watches for new PVCs, finds a matching PV (if possible), and binds them together. The user will always get at least what they asked for, but the volume may be in excess of what was requested. Once bound, `PersistentVolumeClaim` binds are exclusive, regardless of the mode used to bind them.
|
||||||
|
|
||||||
Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the cluster.
|
Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the cluster.
|
||||||
|
|
||||||
@@ -70,7 +49,7 @@ When a user is done with their volume, they can delete the PVC objects from the
|
|||||||
|
|
||||||
### Reclaiming
|
### Reclaiming
|
||||||
|
|
||||||
The reclaim policy for a `PersistentVolume` tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled or Deleted. Retention allows for manual reclamation of the resource. For those volume plugins that support it, deletion removes both the `PersistentVolume` object from Kubernetes as well as deletes associated storage asset in external infrastructure such as AWS EBS, GCE PD or Cinder volume. Volumes that were dynamically provisioned are always deleted. If supported by appropriate volume plugin, recycling performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
|
The reclaim policy for a `PersistentVolume` tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled or Deleted. Retention allows for manual reclamation of the resource. For those volume plugins that support it, deletion removes both the `PersistentVolume` object from Kubernetes as well as deletes associated storage asset in external infrastructure such as AWS EBS, GCE PD or Cinder volume. If supported by appropriate volume plugin, recycling performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
|
||||||
|
|
||||||
## Types of Persistent Volumes
|
## Types of Persistent Volumes
|
||||||
|
|
||||||
@@ -99,8 +78,6 @@ Each PV contains a spec and status, which is the specification and status of the
|
|||||||
kind: PersistentVolume
|
kind: PersistentVolume
|
||||||
metadata:
|
metadata:
|
||||||
name: pv0003
|
name: pv0003
|
||||||
annotations:
|
|
||||||
volume.beta.kubernetes.io/storage-class: "slow"
|
|
||||||
spec:
|
spec:
|
||||||
capacity:
|
capacity:
|
||||||
storage: 5Gi
|
storage: 5Gi
|
||||||
@@ -153,16 +130,6 @@ In the CLI, the access modes are abbreviated to:
|
|||||||
| RDB | x | x | - |
|
| RDB | x | x | - |
|
||||||
| VsphereVolume | x | - | - |
|
| VsphereVolume | x | - | - |
|
||||||
|
|
||||||
### Class
|
|
||||||
|
|
||||||
A PV can have a class, which is specified by setting the
|
|
||||||
`volume.beta.kubernetes.io/storage-class` annotation to the name of a
|
|
||||||
`StorageClass`. A PV of a particular class can only be bound to PVCs requesting
|
|
||||||
that class. A PV with no annotation or its class annotation set to `""` has no
|
|
||||||
class and can only be bound to PVCs that request no particular class.
|
|
||||||
|
|
||||||
In the future after beta, the `volume.beta.kubernetes.io/storage-class`
|
|
||||||
annotation will become an attribute.
|
|
||||||
|
|
||||||
### Recycling Policy
|
### Recycling Policy
|
||||||
|
|
||||||
@@ -194,8 +161,6 @@ kind: PersistentVolumeClaim
|
|||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
metadata:
|
metadata:
|
||||||
name: myclaim
|
name: myclaim
|
||||||
annotations:
|
|
||||||
volume.beta.kubernetes.io/storage-class: "slow"
|
|
||||||
spec:
|
spec:
|
||||||
accessModes:
|
accessModes:
|
||||||
- ReadWriteOnce
|
- ReadWriteOnce
|
||||||
@@ -226,42 +191,6 @@ Claims can specify a [label selector](/docs/user-guide/labels/#label-selectors)
|
|||||||
|
|
||||||
All of the requirements, from both `matchLabels` and `matchExpressions` are ANDed together – they must all be satisfied in order to match.
|
All of the requirements, from both `matchLabels` and `matchExpressions` are ANDed together – they must all be satisfied in order to match.
|
||||||
|
|
||||||
### Class
|
|
||||||
|
|
||||||
A claim can request a particular class by specifying the name of a
|
|
||||||
`StorageClass`using the annotation `volume.beta.kubernetes.io/storage-class`.
|
|
||||||
Only PVs of the requested class, ones with the same annotation as the PVC, can
|
|
||||||
be bound to the PVC.
|
|
||||||
|
|
||||||
PVCs don't necessarily have to request a class. A PVC with its annotation set
|
|
||||||
equal to `""` is always interpreted to be requesting a PV with no class, so it
|
|
||||||
can only be bound to PVs with no class (no annotation or one set equal to
|
|
||||||
`""`). A PVC with no annotation is not quite the same and is treated differently
|
|
||||||
by the cluster depending on whether the
|
|
||||||
[`DefaultStorageClass` admission plugin](/docs/admin/admission-controllers/#defaultstorageclass)
|
|
||||||
is turned on.
|
|
||||||
|
|
||||||
* If the admission plugin is turned on, the administrator may specify a
|
|
||||||
default `StorageClass`. All PVCs that have no annotation can be bound only to
|
|
||||||
PVs of that default. Specifying a default `StorageClass` is done by setting the
|
|
||||||
annotation `storageclass.beta.kubernetes.io/is-default-class` equal to "true" in
|
|
||||||
a `StorageClass` object. If the administrator does not specify a default, the
|
|
||||||
cluster responds to PVC creation as if the admission plugin were turned off. If
|
|
||||||
more than one default is specified, the admission plugin forbids the creation of
|
|
||||||
all PVCs.
|
|
||||||
* If the admission plugin is turned off, there is no notion of a default
|
|
||||||
`StorageClass`. All PVCs that have no annotation can be bound only to PVs that
|
|
||||||
have no class. In this case the PVCs that have no annotation are treated the
|
|
||||||
same way as PVCs that have their annotation set to `""`.
|
|
||||||
|
|
||||||
When a PVC specifies a `selector` in addition to requesting a `StorageClass`,
|
|
||||||
the requirements are ANDed together: only a PV of the requested class and with
|
|
||||||
the requested labels may be bound to the PVC. Note that currently, a PVC with a
|
|
||||||
non-empty `selector` can't have a PV dynamically provisioned for it.
|
|
||||||
|
|
||||||
In the future after beta, the `volume.beta.kubernetes.io/storage-class`
|
|
||||||
annotation will become an attribute.
|
|
||||||
|
|
||||||
## Claims As Volumes
|
## Claims As Volumes
|
||||||
|
|
||||||
Pods access storage by using the claim as a volume. Claims must exist in the same namespace as the pod using the claim. The cluster finds the claim in the pod's namespace and uses it to get the `PersistentVolume` backing the claim. The volume is then mounted to the host and into the pod.
|
Pods access storage by using the claim as a volume. Claims must exist in the same namespace as the pod using the claim. The cluster finds the claim in the pod's namespace and uses it to get the `PersistentVolume` backing the claim. The volume is then mounted to the host and into the pod.
|
||||||
@@ -287,113 +216,3 @@ spec:
|
|||||||
### A Note on Namespaces
|
### A Note on Namespaces
|
||||||
|
|
||||||
`PersistentVolumes` binds are exclusive, and since `PersistentVolumeClaims` are namespaced objects, mounting claims with "Many" modes (`ROX`, `RWX`) is only possible within one namespace.
|
`PersistentVolumes` binds are exclusive, and since `PersistentVolumeClaims` are namespaced objects, mounting claims with "Many" modes (`ROX`, `RWX`) is only possible within one namespace.
|
||||||
|
|
||||||
## StorageClasses
|
|
||||||
|
|
||||||
Each `StorageClass` contains the fields `provisioner` and `parameters`, which
|
|
||||||
are used when a `PersistentVolume` belonging to the class needs to be
|
|
||||||
dynamically provisioned.
|
|
||||||
|
|
||||||
The name of a `StorageClass` object is significant, and is how users can
|
|
||||||
request a particular class. Administrators set the name and other parameters
|
|
||||||
of a class when first creating `StorageClass` objects, and the objects cannot
|
|
||||||
be updated once they are created.
|
|
||||||
|
|
||||||
Administrators can specify a default `StorageClass` just for PVCs that don't
|
|
||||||
request any particular class to bind to: see the
|
|
||||||
[`PersistentVolumeClaim` section](#persistentvolumeclaims)
|
|
||||||
for details.
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
kind: StorageClass
|
|
||||||
apiVersion: extensions/v1beta1
|
|
||||||
metadata:
|
|
||||||
name: standard
|
|
||||||
provisioner: kubernetes.io/aws-ebs
|
|
||||||
parameters:
|
|
||||||
type: gp2
|
|
||||||
```
|
|
||||||
|
|
||||||
### Provisioner
|
|
||||||
Storage classes have a provisioner that determines what volume plugin is used
|
|
||||||
for provisioning PVs. This field must be specified. During beta, the available
|
|
||||||
provisioner types are `kubernetes.io/aws-ebs` and `kubernetes.io/gce-pd`.
|
|
||||||
|
|
||||||
### Parameters
|
|
||||||
Storage classes have parameters that describe volumes belonging to the storage
|
|
||||||
class. Different parameters may be accepted depending on the `provisioner`. For
|
|
||||||
example, the value `io1`, for the parameter `type`, and the parameter
|
|
||||||
`iopsPerGB` are specific to EBS. When a parameter is omitted, some default is
|
|
||||||
used.
|
|
||||||
|
|
||||||
#### AWS
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
kind: StorageClass
|
|
||||||
apiVersion: extensions/v1beta1
|
|
||||||
metadata:
|
|
||||||
name: slow
|
|
||||||
provisioner: kubernetes.io/aws-ebs
|
|
||||||
parameters:
|
|
||||||
type: io1
|
|
||||||
zone: us-east-1d
|
|
||||||
iopsPerGB: "10"
|
|
||||||
```
|
|
||||||
|
|
||||||
* `type`: `io1`, `gp2`, `sc1`, `st1`. See [AWS docs](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) for details. Default: `gp2`.
|
|
||||||
* `zone`: AWS zone. If not specified, a random zone from those where Kubernetes cluster has a node is chosen.
|
|
||||||
* `iopsPerGB`: only for `io1` volumes. I/O operations per second per GiB. AWS volume plugin multiplies this with size of requested volume to compute IOPS of the volume and caps it at 20 000 IOPS (maximum supported by AWS, see [AWS docs](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html). A string is expected here, i.e. `"10"`, not `10`.
|
|
||||||
* `encrypted`: denotes whether the EBS volume should be encrypted or not. Valid values are `"true"` or `"false"`. A string is expected here, i.e. `"true"`, not `true`.
|
|
||||||
* `kmsKeyId`: optional. The full Amazon Resource Name of the key to use when encrypting the volume. If none is supplied but `encrypted` is true, a key is generated by AWS. See AWS docs for valid ARN value.
|
|
||||||
|
|
||||||
#### GCE
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
kind: StorageClass
|
|
||||||
apiVersion: extensions/v1beta1
|
|
||||||
metadata:
|
|
||||||
name: slow
|
|
||||||
provisioner: kubernetes.io/gce-pd
|
|
||||||
parameters:
|
|
||||||
type: pd-standard
|
|
||||||
zone: us-central1-a
|
|
||||||
```
|
|
||||||
|
|
||||||
* `type`: `pd-standard` or `pd-ssd`. Default: `pd-ssd`
|
|
||||||
* `zone`: GCE zone. If not specified, a random zone in the same region as controller-manager will be chosen.
|
|
||||||
|
|
||||||
#### GLUSTERFS
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
apiVersion: extensions/v1beta1
|
|
||||||
kind: StorageClass
|
|
||||||
metadata:
|
|
||||||
name: slow
|
|
||||||
provisioner: kubernetes.io/glusterfs
|
|
||||||
parameters:
|
|
||||||
endpoint: "glusterfs-cluster"
|
|
||||||
resturl: "http://127.0.0.1:8081"
|
|
||||||
restuser: "admin"
|
|
||||||
restuserkey: "password"
|
|
||||||
```
|
|
||||||
|
|
||||||
* `endpoint`: `glusterfs-cluster` is the endpoint/service name which includes GlusterFS trusted pool IP addresses and this parameter is mandatory.
|
|
||||||
* `resturl` : Gluster REST service url which provision gluster volumes on demand. The format should be a valid URL and this is a mandatory parameter for GlusterFS dynamic provisioner.
|
|
||||||
* `restuser` : Gluster REST service user who has access to create volumes in the Gluster Trusted Pool. This parameter is optional, empty string will be used when omitted.
|
|
||||||
* `restuserkey` : Gluster REST service user's password which will be used for authentication to the REST server. This parameter is optional, empty string will be used when omitted.
|
|
||||||
|
|
||||||
#### OpenStack Cinder
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
kind: StorageClass
|
|
||||||
apiVersion: extensions/v1beta1
|
|
||||||
metadata:
|
|
||||||
name: gold
|
|
||||||
provisioner: kubernetes.io/cinder
|
|
||||||
parameters:
|
|
||||||
type: fast
|
|
||||||
availability: nova
|
|
||||||
```
|
|
||||||
|
|
||||||
* `type`: [VolumeType](http://docs.openstack.org/admin-guide/dashboard-manage-volumes.html) created in Cinder. Default is empty.
|
|
||||||
* `availability`: Availability Zone. Default is empty.
|
|
||||||
|
|||||||
@@ -226,7 +226,7 @@ It's not necessary to "discover" the governing Service of a Pet Set, since it's
|
|||||||
|
|
||||||
Usually pets also need to find their peers. In the previous nginx example, we just used `kubectl` to get the names of existing pods, and as humans, we could tell which ones belonged to a given Pet Set. Another way to find peers is by contacting the API server, just like `kubectl`, but that has several disadvantages (you end up implementing a Kubernetes specific init system that runs as pid 1 in your application container).
|
Usually pets also need to find their peers. In the previous nginx example, we just used `kubectl` to get the names of existing pods, and as humans, we could tell which ones belonged to a given Pet Set. Another way to find peers is by contacting the API server, just like `kubectl`, but that has several disadvantages (you end up implementing a Kubernetes specific init system that runs as pid 1 in your application container).
|
||||||
|
|
||||||
Pet Set gives you a way to disover your peers using DNS records. To illustrate this we can use the previous example (note: one usually doesn't `apt-get` in a container).
|
Pet Set gives you a way to discover your peers using DNS records. To illustrate this we can use the previous example (note: one usually doesn't `apt-get` in a container).
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
$ kubectl exec -it web-0 /bin/sh
|
$ kubectl exec -it web-0 /bin/sh
|
||||||
|
|||||||
@@ -19,7 +19,7 @@ This example shows you how to "carry over" runtime state across Pet restart by s
|
|||||||
|
|
||||||
### Background
|
### Background
|
||||||
|
|
||||||
Applications that incrementally build state usually need strong guarantees that they will not restart for extended durations. This is tricky to achieve with containers, so instead, we will ensure that the results of previous computations are trasferred to future pets. Doing so is straight-forward using vanilla Persistent Volumes (which Pet Set already gives you), unless the volume mount point itself needs to be initialized for the Pet to start. This is exactly the case with "virtual machine" docker images, like those based on ubuntu or fedora. Such images embed the entier rootfs of the distro, including package managers like `apt-get` that assume a certain layout of the filesystem. Meaning:
|
Applications that incrementally build state usually need strong guarantees that they will not restart for extended durations. This is tricky to achieve with containers, so instead, we will ensure that the results of previous computations are trasferred to future pets. Doing so is straightforward using vanilla Persistent Volumes (which Pet Set already gives you), unless the volume mount point itself needs to be initialized for the Pet to start. This is exactly the case with "virtual machine" docker images, like those based on ubuntu or fedora. Such images embed the entier rootfs of the distro, including package managers like `apt-get` that assume a certain layout of the filesystem. Meaning:
|
||||||
|
|
||||||
* If you mount an empty volume under `/usr`, you won't be able to `apt-get`
|
* If you mount an empty volume under `/usr`, you won't be able to `apt-get`
|
||||||
* If you mount an empty volume under `/lib`, all your `apt-gets` will fail because there are no system libraries
|
* If you mount an empty volume under `/lib`, all your `apt-gets` will fail because there are no system libraries
|
||||||
@@ -166,7 +166,7 @@ vm-1.ub.default.svc.cluster.local
|
|||||||
|
|
||||||
### Nginx master/slave cluster
|
### Nginx master/slave cluster
|
||||||
|
|
||||||
Lets create a Pet Set that writes out its own config based on a list of peers at initalization time, as described above.
|
Lets create a Pet Set that writes out its own config based on a list of peers at initialization time, as described above.
|
||||||
|
|
||||||
Download and create [this](petset_peers.yaml) petset. It will setup 2 nginx webservers, but the second one will proxy all requests to the first:
|
Download and create [this](petset_peers.yaml) petset. It will setup 2 nginx webservers, but the second one will proxy all requests to the first:
|
||||||
|
|
||||||
@@ -192,7 +192,7 @@ web-0 1/1 Running 0 1m
|
|||||||
web-1 1/1 Running 0 47s
|
web-1 1/1 Running 0 47s
|
||||||
```
|
```
|
||||||
|
|
||||||
web-1 will redirect all requests to it's "master":
|
web-1 will redirect all requests to its "master":
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
$ kubectl exec -it web-1 -- curl localhost
|
$ kubectl exec -it web-1 -- curl localhost
|
||||||
|
|||||||
@@ -177,7 +177,7 @@ To consume a Secret in a volume in a Pod:
|
|||||||
1. Create a secret or use an existing one. Multiple pods can reference the same secret.
|
1. Create a secret or use an existing one. Multiple pods can reference the same secret.
|
||||||
1. Modify your Pod definition to add a volume under `spec.volumes[]`. Name the volume anything, and have a `spec.volumes[].secret.secretName` field equal to the name of the secret object.
|
1. Modify your Pod definition to add a volume under `spec.volumes[]`. Name the volume anything, and have a `spec.volumes[].secret.secretName` field equal to the name of the secret object.
|
||||||
1. Add a `spec.containers[].volumeMounts[]` to each container that needs the secret. Specify `spec.containers[].volumeMounts[].readOnly = true` and `spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the secrets to appear.
|
1. Add a `spec.containers[].volumeMounts[]` to each container that needs the secret. Specify `spec.containers[].volumeMounts[].readOnly = true` and `spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the secrets to appear.
|
||||||
1. Modify your image and/or command line so that the the program looks for files in that directory. Each key in the secret `data` map becomes the filename under `mountPath`.
|
1. Modify your image and/or command line so that the program looks for files in that directory. Each key in the secret `data` map becomes the filename under `mountPath`.
|
||||||
|
|
||||||
This is an example of a pod that mounts a secret in a volume:
|
This is an example of a pod that mounts a secret in a volume:
|
||||||
|
|
||||||
@@ -293,7 +293,7 @@ To use a secret in an environment variable in a pod:
|
|||||||
|
|
||||||
1. Create a secret or use an existing one. Multiple pods can reference the same secret.
|
1. Create a secret or use an existing one. Multiple pods can reference the same secret.
|
||||||
1. Modify your Pod definition in each container that you wish to consume the value of a secret key to add an environment variable for each secret key you wish to consume. The environment variable that consumes the secret key should populate the secret's name and key in `env[x].valueFrom.secretKeyRef`.
|
1. Modify your Pod definition in each container that you wish to consume the value of a secret key to add an environment variable for each secret key you wish to consume. The environment variable that consumes the secret key should populate the secret's name and key in `env[x].valueFrom.secretKeyRef`.
|
||||||
1. Modify your image and/or command line so that the the program looks for values in the specified environment variables
|
1. Modify your image and/or command line so that the program looks for values in the specified environment variables
|
||||||
|
|
||||||
This is an example of a pod that mounts a secret in a volume:
|
This is an example of a pod that mounts a secret in a volume:
|
||||||
|
|
||||||
|
|||||||
@@ -48,7 +48,7 @@ for more details.
|
|||||||
|
|
||||||
#### `selinuxOptions`
|
#### `selinuxOptions`
|
||||||
|
|
||||||
Volumes which support SELinux labeling are relabled to be accessable
|
Volumes which support SELinux labeling are relabled to be accessible
|
||||||
by the label specified unders `seLinuxOptions`. Usually you will only
|
by the label specified unders `seLinuxOptions`. Usually you will only
|
||||||
need to set the `level` section. This sets the SELinux MCS label given
|
need to set the `level` section. This sets the SELinux MCS label given
|
||||||
to all containers within the pod as well as the volume.
|
to all containers within the pod as well as the volume.
|
||||||
|
|||||||
@@ -460,7 +460,7 @@ within AWS Certificate Manager.
|
|||||||
"metadata": {
|
"metadata": {
|
||||||
"name": "my-service",
|
"name": "my-service",
|
||||||
"annotations": {
|
"annotations": {
|
||||||
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol=": "(https|http|ssl|tcp)"
|
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "(https|http|ssl|tcp)"
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
```
|
```
|
||||||
|
|||||||
@@ -32,7 +32,7 @@ $ kubectl proxy --www=docs/user-guide/update-demo/local/ &
|
|||||||
I0218 15:18:31.623279 67480 proxy.go:36] Starting to serve on localhost:8001
|
I0218 15:18:31.623279 67480 proxy.go:36] Starting to serve on localhost:8001
|
||||||
```
|
```
|
||||||
|
|
||||||
Now visit the the [demo website](http://localhost:8001/static). You won't see anything much quite yet.
|
Now visit the [demo website](http://localhost:8001/static). You won't see anything much quite yet.
|
||||||
|
|
||||||
### Step Two: Run the replication controller
|
### Step Two: Run the replication controller
|
||||||
|
|
||||||
|
|||||||
@@ -10,7 +10,7 @@ assignees:
|
|||||||
On-disk files in a container are ephemeral, which presents some problems for
|
On-disk files in a container are ephemeral, which presents some problems for
|
||||||
non-trivial applications when running in containers. First, when a container
|
non-trivial applications when running in containers. First, when a container
|
||||||
crashes kubelet will restart it, but the files will be lost - the
|
crashes kubelet will restart it, but the files will be lost - the
|
||||||
container starts with a clean slate. Second, when running containers together
|
container starts with a clean state. Second, when running containers together
|
||||||
in a `Pod` it is often necessary to share files between those containers. The
|
in a `Pod` it is often necessary to share files between those containers. The
|
||||||
Kubernetes `Volume` abstraction solves both of these problems.
|
Kubernetes `Volume` abstraction solves both of these problems.
|
||||||
|
|
||||||
@@ -125,7 +125,7 @@ Watch out when using this type of volume, because:
|
|||||||
* when Kubernetes adds resource-aware scheduling, as is planned, it will not be
|
* when Kubernetes adds resource-aware scheduling, as is planned, it will not be
|
||||||
able to account for resources used by a `hostPath`
|
able to account for resources used by a `hostPath`
|
||||||
* the directories created on the underlying hosts are only writable by root, you either need
|
* the directories created on the underlying hosts are only writable by root, you either need
|
||||||
to run your process as root in a priveleged container or modify the file permissions on
|
to run your process as root in a privileged container or modify the file permissions on
|
||||||
the host to be able to write to a `hostPath` volume
|
the host to be able to write to a `hostPath` volume
|
||||||
|
|
||||||
#### Example pod
|
#### Example pod
|
||||||
@@ -244,7 +244,7 @@ There are some restrictions when using an awsElasticBlockStore volume:
|
|||||||
|
|
||||||
#### Creating an EBS volume
|
#### Creating an EBS volume
|
||||||
|
|
||||||
Before you can use a EBS volume with a pod, you need to create it.
|
Before you can use an EBS volume with a pod, you need to create it.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
aws ec2 create-volume --availability-zone eu-west-1a --size 10 --volume-type gp2
|
aws ec2 create-volume --availability-zone eu-west-1a --size 10 --volume-type gp2
|
||||||
@@ -370,7 +370,7 @@ writers simultaneously.
|
|||||||
__Important: You must have your own Ceph server running with the share exported
|
__Important: You must have your own Ceph server running with the share exported
|
||||||
before you can use it__
|
before you can use it__
|
||||||
|
|
||||||
See the [CephFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/cephfs/) for more details.
|
See the [CephFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/cephfs/) for more details.
|
||||||
|
|
||||||
### gitRepo
|
### gitRepo
|
||||||
|
|
||||||
@@ -379,7 +379,7 @@ mounts an empty directory and clones a git repository into it for your pod to
|
|||||||
use. In the future, such volumes may be moved to an even more decoupled model,
|
use. In the future, such volumes may be moved to an even more decoupled model,
|
||||||
rather than extending the Kubernetes API for every such use case.
|
rather than extending the Kubernetes API for every such use case.
|
||||||
|
|
||||||
Here is a example for gitRepo volume:
|
Here is an example for gitRepo volume:
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
|
|||||||
+1
-20
@@ -92,14 +92,13 @@ function px(n){
|
|||||||
|
|
||||||
var kub = (function () {
|
var kub = (function () {
|
||||||
var HEADER_HEIGHT;
|
var HEADER_HEIGHT;
|
||||||
var html, header, mainNav, quickstartButton, hero, encyclopedia, footer, wishField, headlineWrapper;
|
var html, header, mainNav, quickstartButton, hero, encyclopedia, footer, headlineWrapper;
|
||||||
|
|
||||||
$(document).ready(function () {
|
$(document).ready(function () {
|
||||||
html = $('html');
|
html = $('html');
|
||||||
body = $('body');
|
body = $('body');
|
||||||
header = $('header');
|
header = $('header');
|
||||||
mainNav = $('#mainNav');
|
mainNav = $('#mainNav');
|
||||||
wishField = $('#wishField');
|
|
||||||
quickstartButton = $('#quickstartButton');
|
quickstartButton = $('#quickstartButton');
|
||||||
hero = $('#hero');
|
hero = $('#hero');
|
||||||
encyclopedia = $('#encyclopedia');
|
encyclopedia = $('#encyclopedia');
|
||||||
@@ -112,13 +111,11 @@ var kub = (function () {
|
|||||||
window.addEventListener('resize', resetTheView);
|
window.addEventListener('resize', resetTheView);
|
||||||
window.addEventListener('scroll', resetTheView);
|
window.addEventListener('scroll', resetTheView);
|
||||||
window.addEventListener('keydown', handleKeystrokes);
|
window.addEventListener('keydown', handleKeystrokes);
|
||||||
wishField[0].addEventListener('keydown', handleKeystrokes);
|
|
||||||
|
|
||||||
document.onunload = function(){
|
document.onunload = function(){
|
||||||
window.removeEventListener('resize', resetTheView);
|
window.removeEventListener('resize', resetTheView);
|
||||||
window.removeEventListener('scroll', resetTheView);
|
window.removeEventListener('scroll', resetTheView);
|
||||||
window.removeEventListener('keydown', handleKeystrokes);
|
window.removeEventListener('keydown', handleKeystrokes);
|
||||||
wishField[0].removeEventListener('keydown', handleKeystrokes);
|
|
||||||
};
|
};
|
||||||
|
|
||||||
setInterval(setFooterType, 10);
|
setInterval(setFooterType, 10);
|
||||||
@@ -189,24 +186,8 @@ var kub = (function () {
|
|||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
function submitWish(textfield) {
|
|
||||||
window.location.replace("https://github.com/kubernetes/kubernetes.github.io/issues/new?title=I%20wish%20" +
|
|
||||||
window.location.pathname + "%20" + textfield.value + "&body=I%20wish%20" +
|
|
||||||
window.location.pathname + "%20" + textfield.value);
|
|
||||||
|
|
||||||
textfield.value = '';
|
|
||||||
textfield.blur();
|
|
||||||
}
|
|
||||||
|
|
||||||
function handleKeystrokes(e) {
|
function handleKeystrokes(e) {
|
||||||
switch (e.which) {
|
switch (e.which) {
|
||||||
case 13: {
|
|
||||||
if (e.currentTarget === wishField[0]) {
|
|
||||||
submitWish(wishField[0]);
|
|
||||||
}
|
|
||||||
break;
|
|
||||||
}
|
|
||||||
|
|
||||||
case 27: {
|
case 27: {
|
||||||
if (html.hasClass('open-nav')) {
|
if (html.hasClass('open-nav')) {
|
||||||
toggleMenu();
|
toggleMenu();
|
||||||
|
|||||||
@@ -0,0 +1,6 @@
|
|||||||
|
[build]
|
||||||
|
command = "make build"
|
||||||
|
publish = "_site"
|
||||||
|
|
||||||
|
[context.deploy-preview]
|
||||||
|
command = "make build-preview"
|
||||||
@@ -1,14 +0,0 @@
|
|||||||
{
|
|
||||||
"name": "githubpagessites",
|
|
||||||
"description": "Version 1.1 of the docs for Kubernetes",
|
|
||||||
"version": "1.1",
|
|
||||||
"private": true,
|
|
||||||
"license": "Apache Version 2.0",
|
|
||||||
"author": "The Kubernetes Authors",
|
|
||||||
"engines": {
|
|
||||||
"node": "~4.2"
|
|
||||||
},
|
|
||||||
"dependencies": {
|
|
||||||
"express": "^4.13.4"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
Reference in New Issue
Block a user