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

Merge branch 'master' into patch-7

Browse Source
This commit is contained in:
Wang Jie
2017-03-01 09:53:37 +08:00
committed by GitHub
parent dd595ae05b 04f2e50caa
commit fd9ff4c4e0
83 changed files with 1775 additions and 1364 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/admin/authentication.md
+6 -6
View File
@@ -85,9 +85,9 @@ See [APPENDIX](#appendix) for how to generate a client cert.
The API server reads bearer tokens from a file when given the `--token-auth-file=SOMEFILE` option on the command line. Currently, tokens last indefinitely, and the token list cannot be
changed without restarting API server.
The token file format is implemented in `plugin/pkg/auth/authenticator/token/tokenfile/...`
and is a csv file with a minimum of 3 columns: token, user name, user uid, followed by
optional group names. Note, if you have more than one group the column must be double quoted e.g.
The token file is a csv file with a minimum of 3 columns: token, user name, user uid,
followed by optional group names. Note, if you have more than one group the column must be
double quoted e.g.
```conf
token,user,uid,"group1,group2,group3"
@@ -115,9 +115,9 @@ and the password cannot be changed without restarting API server. Note that basi
authentication is currently supported for convenience while we finish making the
more secure modes described above easier to use.
The basic auth file format is implemented in `plugin/pkg/auth/authenticator/password/passwordfile/...`
and is a csv file with a minimum of 3 columns: password, user name, user id, followed by
optional group names. Note, if you have more than one group the column must be double quoted e.g.
The basic auth file is a csv file with a minimum of 3 columns: password,
user name, user id, followed by optional group names. Note, if you have more than
one group the column must be double quoted e.g.
```conf
password,user,uid,"group1,group2,group3"
docs/admin/etcd.md
+1 -1
View File
@@ -20,7 +20,7 @@ Data Reliability: for reasonable safety, either etcd needs to be run as a
etcd) or etcd's data directory should be located on durable storage (e.g., GCE's
persistent disk). In either case, if high availability is required--as it might
be in a production cluster--the data directory ought to be [backed up
periodically](https://coreos.com/etcd/docs/2.2.1/admin_guide.html#disaster-recovery),
periodically](https://coreos.com/etcd/docs/latest/op-guide/recovery.html),
to reduce downtime in case of corruption.
## Default configuration
docs/admin/federation-controller-manager.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
title: federation-controller-mananger
title: federation-controller-manager
notitle: true
---
docs/admin/garbage-collection.md
+25 -6
View File
@@ -24,9 +24,9 @@ threshold has been met.
### Container Collection
The policy for garbage collecting containers considers three user-defined variables. `MinAge` is the minimum age at which a container can be garbage collected. `MaxPerPodContainer` is the maximum number of dead containers any single
pod (UID, container name) pair is allowed to have. `MaxContainers` is the maximum number of total dead containers. These variables can be individually disabled by setting 'MinAge' to zero and setting 'MaxPerPodContainer' and 'MaxContainers' respectively to less than zero.
pod (UID, container name) pair is allowed to have. `MaxContainers` is the maximum number of total dead containers. These variables can be individually disabled by setting `MinAge` to zero and setting `MaxPerPodContainer` and `MaxContainers` respectively to less than zero.
Kubelet will act on containers that are unidentified, deleted, or outside of the boundaries set by the previously mentioned flags. The oldest containers will generally be removed first. 'MaxPerPodContainer' and 'MaxContainer' may potentially conflict with each other in situations where retaining the maximum number of containers per pod ('MaxPerPodContainer') would go outside the allowable range of global dead containers ('MaxContainers'). 'MaxPerPodContainer' would be adjusted in this situation: A worst case scenario would be to downgrade 'MaxPerPodContainer' to 1 and evict the oldest containers. Additionally, containers owned by pods that have been deleted are removed once they are older than `MinAge`.
Kubelet will act on containers that are unidentified, deleted, or outside of the boundaries set by the previously mentioned flags. The oldest containers will generally be removed first. `MaxPerPodContainer` and `MaxContainer` may potentially conflict with each other in situations where retaining the maximum number of containers per pod (`MaxPerPodContainer`) would go outside the allowable range of global dead containers (`MaxContainers`). `MaxPerPodContainer` would be adjusted in this situation: A worst case scenario would be to downgrade `MaxPerPodContainer` to 1 and evict the oldest containers. Additionally, containers owned by pods that have been deleted are removed once they are older than `MinAge`.
Containers that are not managed by kubelet are not subject to container garbage collection.
@@ -42,15 +42,34 @@ to free. Default is 80%.
We also allow users to customize garbage collection policy through the following kubelet flags:
1. `minimum-container-ttl-duration`, minimum age for a finished container before it is
garbage collected. Default is 1 minute.
garbage collected. Default is 0 minute, which means any finished container will be garbaged collected.
2. `maximum-dead-containers-per-container`, maximum number of old instances to retain
per container. Default is 2.
per container. Default is 1.
3. `maximum-dead-containers`, maximum number of old instances of containers to retain globally.
Default is 100.
Default is -1, which means there is no global limit.
Containers can potentially be garbage collected before their usefulness has expired. These containers
can contain logs and other data that can be useful for troubleshooting. A sufficiently large value for
`maximum-dead-containers-per-container` is highly recommended to allow at least 2 dead containers to be
`maximum-dead-containers-per-container` is highly recommended to allow at least 1 dead container to be
retained per expected container. A higher value for `maximum-dead-containers` is also recommended for a
similar reason.
See [this issue](https://github.com/kubernetes/kubernetes/issues/13287) for more details.
### Deprecation
Some kubelet Garbage Collection features in this doc will be replaced by kubelet eviction in the future.
Including:
| Existing Flag | New Flag | Rationale |
| ------------- | -------- | --------- |
| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection |
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior |
| `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context |
| `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context |
| `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context |
| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | eviction generalizes disk thresholds to other resources |
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | eviction generalizes disk pressure transition to other resources |
See [kubelet eviction design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/kubelet-eviction.md) for more details.
docs/admin/kube-proxy.md
-1
View File
@@ -41,7 +41,6 @@ DynamicKubeletConfig=true|false (ALPHA - default=false)
DynamicVolumeProvisioning=true|false (ALPHA - default=true)
ExperimentalHostUserNamespaceDefaulting=true|false (ALPHA - default=false)
StreamingProxyRedirects=true|false (ALPHA - default=false)
--google-json-key string The Google Cloud Platform Service Account JSON Key to use for authentication.
--healthz-bind-address ip The IP address for the health check server to serve on, defaulting to 127.0.0.1 (set to 0.0.0.0 for all interfaces) (default 127.0.0.1)
--healthz-port int32 The port to bind the health check server. Use 0 to disable. (default 10249)
--hostname-override string If non-empty, will use this string as identification instead of the actual hostname.
docs/admin/kube-scheduler.md
-1
View File
@@ -36,7 +36,6 @@ DynamicKubeletConfig=true|false (ALPHA - default=false)
DynamicVolumeProvisioning=true|false (ALPHA - default=true)
ExperimentalHostUserNamespaceDefaulting=true|false (ALPHA - default=false)
StreamingProxyRedirects=true|false (ALPHA - default=false)
--google-json-key string The Google Cloud Platform Service Account JSON Key to use for authentication.
--hard-pod-affinity-symmetric-weight int RequiredDuringScheduling affinity is not symmetric, but there is an implicit PreferredDuringScheduling affinity rule corresponding to every RequiredDuringScheduling affinity rule. --hard-pod-affinity-symmetric-weight represents the weight of implicit PreferredDuringScheduling affinity rule. (default 1)
--kube-api-burst int32 Burst to use while talking with Kubernetes apiserver (default 100)
--kube-api-content-type string Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf")
docs/admin/kubeadm.md
+43 -41
View File
@@ -31,7 +31,7 @@ server, as well as an additional kubeconfig file for administration.
controller manager and scheduler, and placing them in
`/etc/kubernetes/manifests`. The kubelet watches this directory for static
resources to create on startup. These are the core components of Kubernetes, and
once they are up and running we can use `kubectl` to set up/manage any
once they are up and running we can use `kubectl` to set up or manage any
additional components.
1. kubeadm installs any add-on components, such as DNS or discovery, via the API
@@ -180,49 +180,49 @@ available as configuration file options.
### Sample Master Configuration
```yaml
apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
api:
advertiseAddresses:
- <address1|string>
- <address2|string>
bindPort: <int>
externalDNSNames:
- <dnsname1|string>
- <dnsname2|string>
authorizationMode: <string>
cloudProvider: <string>
discovery:
bindPort: <int>
etcd:
endpoints:
- <endpoint1|string>
- <endpoint2|string>
caFile: <path|string>
certFile: <path|string>
keyFile: <path|string>
kubernetesVersion: <string>
networking:
dnsDomain: <string>
serviceSubnet: <cidr>
podSubnet: <cidr>
secrets:
givenToken: <token|string>
```
```yaml
apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
api:
advertiseAddresses:
- <address1|string>
- <address2|string>
bindPort: <int>
externalDNSNames:
- <dnsname1|string>
- <dnsname2|string>
authorizationMode: <string>
cloudProvider: <string>
discovery:
bindPort: <int>
etcd:
endpoints:
- <endpoint1|string>
- <endpoint2|string>
caFile: <path|string>
certFile: <path|string>
keyFile: <path|string>
kubernetesVersion: <string>
networking:
dnsDomain: <string>
serviceSubnet: <cidr>
podSubnet: <cidr>
secrets:
givenToken: <token|string>
```
### Sample Node Configuration
```yaml
apiVersion: kubeadm.k8s.io/v1alpha1
kind: NodeConfiguration
apiPort: <int>
discoveryPort: <int>
masterAddresses:
- <master1>
secrets:
givenToken: <token|string>
```
```yaml
apiVersion: kubeadm.k8s.io/v1alpha1
kind: NodeConfiguration
apiPort: <int>
discoveryPort: <int>
masterAddresses:
- <master1>
secrets:
givenToken: <token|string>
```
## Automating kubeadm
@@ -258,6 +258,8 @@ These environment variables are a short-term solution, eventually they will be i
| `KUBE_ETCD_IMAGE` | `gcr.io/google_containers/etcd-<arch>:2.2.5` | The etcd container image to use. |
| `KUBE_REPO_PREFIX` | `gcr.io/google_containers` | The image prefix for all images that are used. |
If you want to use kubeadm with an http proxy, you may need to configure it to support http_proxy, https_proxy, or no_proxy.
## Releases and release notes
If you already have kubeadm installed and want to upgrade, run `apt-get update && apt-get upgrade` or `yum update` to get the latest version of kubeadm.
docs/admin/limitrange/index.md
+1 -1
View File
@@ -24,7 +24,7 @@ each namespace.
3. Users may create a pod which consumes resources just below the capacity of a machine. The left over space
may be too small to be useful, but big enough for the waste to be costly over the entire cluster. As a result,
the cluster operator may want to set limits that a pod must consume at least 20% of the memory and CPU of their
average node size in order to provide for more uniform scheduling and to limit waste.
average node size in order to provide for more uniform scheduling and limit waste.
This example demonstrates how limits can be applied to a Kubernetes [namespace](/docs/admin/namespaces/walkthrough/) to control
min/max resource limits per pod. In addition, this example demonstrates how you can
docs/admin/multiple-schedulers.md
+3 -3
View File
@@ -95,7 +95,7 @@ Now that our second scheduler is running, let's create some pods, and direct the
scheduler in that pod spec. Let's look at three examples.
1. Pod spec without any scheduler name
- Pod spec without any scheduler name
{% include code.html language="yaml" file="multiple-schedulers/pod1.yaml" ghlink="/docs/admin/multiple-schedulers/pod1.yaml" %}
@@ -108,7 +108,7 @@ scheduler in that pod spec. Let's look at three examples.
kubectl create -f pod1.yaml
```
2. Pod spec with `default-scheduler`
- Pod spec with `default-scheduler`
{% include code.html language="yaml" file="multiple-schedulers/pod2.yaml" ghlink="/docs/admin/multiple-schedulers/pod2.yaml" %}
@@ -121,7 +121,7 @@ scheduler in that pod spec. Let's look at three examples.
kubectl create -f pod2.yaml
```
3. Pod spec with `my-scheduler`
- Pod spec with `my-scheduler`
{% include code.html language="yaml" file="multiple-schedulers/pod3.yaml" ghlink="/docs/admin/multiple-schedulers/pod3.yaml" %}
docs/admin/namespaces/walkthrough.md
+1 -1
View File
@@ -145,7 +145,7 @@ dev
At this point, all requests we make to the Kubernetes cluster from the command line are scoped to the development namespace.
Let's create some content.
Let's create some contents.
```shell
$ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
docs/admin/network-plugins.md
+1 -1
View File
@@ -49,7 +49,7 @@ The plugin requires a few things:
* The standard CNI `bridge`, `lo` and `host-local` plugins are required, at minimum version 0.2.0. Kubenet will first search for them in `/opt/cni/bin`. Specify `network-plugin-dir` to supply additional search path. The first found match will take effect.
* Kubelet must be run with the `--network-plugin=kubenet` argument to enable the plugin
* Kubelet should also be run with the `--non-masquerade-cidr=<clusterCidr>` argumment to ensure traffic to IPs outside this range will use IP masquerade.
* Kubelet should also be run with the `--non-masquerade-cidr=<clusterCidr>` argument to ensure traffic to IPs outside this range will use IP masquerade.
* The node must be assigned an IP subnet through either the `--pod-cidr` kubelet command-line option or the `--allocate-node-cidrs=true --cluster-cidr=<cidr>` controller-manager command-line options.
### Customizing the MTU (with kubenet)
docs/admin/node.md
+3
View File
@@ -176,6 +176,9 @@ For self-registration, the kubelet is started with the following options:
- `--kubeconfig=` - Path to credentials to authenticate itself to the apiserver.
- `--cloud-provider=` - How to talk to a cloud provider to read metadata about itself.
- `--register-node` - Automatically register with the API server.
- `--node-ip` IP address of the node.
- `--node-labels` - Labels to add when registering the node in the cluster.
- `--node-status-update-frequency` - Specifies how often kubelet posts node status to master.
Currently, any kubelet is authorized to create/modify any node resource, but in practice it only creates/modifies
its own. (In the future, we plan to only allow a kubelet to modify its own node resource.)
docs/admin/salt.md
+6 -6
View File
@@ -10,11 +10,11 @@ The Salt scripts are shared across multiple hosting providers and depending on w
## Salt cluster setup
The **salt-master** service runs on the kubernetes-master [(except on the default GCE setup)](#standalone-salt-configuration-on-gce).
The **salt-master** service runs on the kubernetes-master [(except on the default GCE and OpenStack-Heat setup)](#standalone-salt-configuration-on-gce-and-others).
The **salt-minion** service runs on the kubernetes-master and each kubernetes-node in the cluster.
Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file [(except on GCE)](#standalone-salt-configuration-on-gce).
Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file [(except on GCE and OpenStack-Heat)](#standalone-salt-configuration-on-gce-and-others).
```shell
[root@kubernetes-master] $ cat /etc/salt/minion.d/master.conf
@@ -25,15 +25,15 @@ The salt-master is contacted by each salt-minion and depending upon the machine
If you are running the Vagrant based environment, the **salt-api** service is running on the kubernetes-master. It is configured to enable the vagrant user to introspect the salt cluster in order to find out about machines in the Vagrant environment via a REST API.
## Standalone Salt Configuration on GCE
## Standalone Salt Configuration on GCE and others
On GCE, the master and nodes are all configured as [standalone minions](http://docs.saltstack.com/en/latest/topics/tutorials/standalone_minion.html). The configuration for each VM is derived from the VM's [instance metadata](https://cloud.google.com/compute/docs/metadata) and then stored in Salt grains (`/etc/salt/minion.d/grains.conf`) and pillars (`/srv/salt-overlay/pillar/cluster-params.sls`) that local Salt uses to enforce state.
On GCE and OpenStack, using the Openstack-Heat provider, the master and nodes are all configured as [standalone minions](http://docs.saltstack.com/en/latest/topics/tutorials/standalone_minion.html). The configuration for each VM is derived from the VM's [instance metadata](https://cloud.google.com/compute/docs/metadata) and then stored in Salt grains (`/etc/salt/minion.d/grains.conf`) and pillars (`/srv/salt-overlay/pillar/cluster-params.sls`) that local Salt uses to enforce state.
All remaining sections that refer to master/minion setups should be ignored for GCE. One fallout of the GCE setup is that the Salt mine doesn't exist - there is no sharing of configuration amongst nodes.
All remaining sections that refer to master/minion setups should be ignored for GCE and OpenStack. One fallout of this setup is that the Salt mine doesn't exist - there is no sharing of configuration amongst nodes.
## Salt security
*(Not applicable on default GCE setup.)*
*(Not applicable on default GCE and OpenStack-Heat setup.)*
Security is not enabled on the salt-master, and the salt-master is configured to auto-accept incoming requests from minions. It is not recommended to use this security configuration in production environments without deeper study. (In some environments this isn't as bad as it might sound if the salt master port isn't externally accessible and you trust everyone on your network.)
docs/admin/service-accounts-admin.md
+3 -2
View File
@@ -71,8 +71,9 @@ account. To create additional API tokens for a service account, create a secret
of type `ServiceAccountToken` with an annotation referencing the service
account, and the controller will update it with a generated token:
```json
secret.json:
```json
{
"kind": "Secret",
"apiVersion": "v1",
@@ -100,4 +101,4 @@ kubectl delete secret mysecretname
### Service Account Controller
Service Account Controller manages ServiceAccount inside namespaces, and ensures
a ServiceAccount named "default" exists in every active namespace.
a ServiceAccount named "default" exists in every active namespace.
docs/admin/static-pods.md
+12 -11
View File
@@ -26,7 +26,7 @@ For example, this is how to start a simple web server as a static pod:
[joe@host ~] $ ssh my-node1
```
2. Choose a directory, say `/etc/kubelet.d` and place a web server pod definition there, e.g. `/etc/kubernetes.d/static-web.yaml`:
2. Choose a directory, say `/etc/kubelet.d` and place a web server pod definition there, e.g. `/etc/kubelet.d/static-web.yaml`:
```
[root@my-node1 ~] $ mkdir /etc/kubernetes.d/
@@ -51,7 +51,7 @@ For example, this is how to start a simple web server as a static pod:
3. Configure your kubelet daemon on the node to use this directory by running it with `--pod-manifest-path=/etc/kubelet.d/` argument.
On Fedora edit `/etc/kubernetes/kubelet` to include this line:
```conf
```
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
```
@@ -73,8 +73,8 @@ When kubelet starts, it automatically starts all pods defined in directory speci
```shell
[joe@my-node1 ~] $ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
```
If we look at our Kubernetes API server (running on host `my-master`), we see that a new mirror-pod was created there too:
@@ -82,9 +82,9 @@ If we look at our Kubernetes API server (running on host `my-master`), we see th
```shell
[joe@host ~] $ ssh my-master
[joe@my-master ~] $ kubectl get pods
POD IP CONTAINER(S) IMAGE(S) HOST LABELS STATUS CREATED MESSAGE
static-web-my-node1 172.17.0.3 my-node1/192.168.100.71 role=myrole Running 11 minutes
web nginx Running 11 minutes
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 2m
```
Labels from the static pod are propagated into the mirror-pod and can be used as usual for filtering.
@@ -95,8 +95,9 @@ Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/
[joe@my-master ~] $ kubectl delete pod static-web-my-node1
pods/static-web-my-node1
[joe@my-master ~] $ kubectl get pods
POD IP CONTAINER(S) IMAGE(S) HOST ...
static-web-my-node1 172.17.0.3 my-node1/192.168.100.71 ...
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 12s
```
Back to our `my-node1` host, we can try to stop the container manually and see, that kubelet automatically restarts it in a while:
@@ -115,11 +116,11 @@ CONTAINER ID IMAGE COMMAND CREATED ...
Running kubelet periodically scans the configured directory (`/etc/kubelet.d` in our example) for changes and adds/removes pods as files appear/disappear in this directory.
```shell
[joe@my-node1 ~] $ mv /etc/kubernetes.d/static-web.yaml /tmp
[joe@my-node1 ~] $ mv /etc/kubelet.d/static-web.yaml /tmp
[joe@my-node1 ~] $ sleep 20
[joe@my-node1 ~] $ docker ps
// no nginx container is running
[joe@my-node1 ~] $ mv /tmp/static-web.yaml /etc/kubernetes.d/
[joe@my-node1 ~] $ mv /tmp/static-web.yaml /etc/kubelet.d/
[joe@my-node1 ~] $ sleep 20
[joe@my-node1 ~] $ docker ps
CONTAINER ID IMAGE COMMAND CREATED ...