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

Merge branch 'master' into page-version

Browse Source
This commit is contained in:
Andrew Chen
2017-01-26 16:26:31 -08:00
committed by GitHub
parent 07aa716422 e3494fd143
commit 0c8c31235a
74 changed files with 1219 additions and 688 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/admin/authentication.md
+3 -2
View File
@@ -116,10 +116,11 @@ 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 3 columns: password, user name, user id.
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.
```conf
password,user,uid
password,user,uid,"group1,group2,group3"
```
When using basic authentication from an http client, the API server expects an `Authorization` header
docs/admin/authorization.md
+33 -7
View File
@@ -85,8 +85,8 @@ properties:
- `kind`, type string: valid values are "Policy". Allows versioning and conversion of the policy format.
- `spec` property set to a map with the following properties:
- Subject-matching properties:
- `user`, type string; the user-string from `--token-auth-file`. If you specify `user`, it must match the username of the authenticated user. `*` matches all requests.
- `group`, type string; if you specify `group`, it must match one of the groups of the authenticated user. `*` matches all requests.
- `user`, type string; the user-string from `--token-auth-file`. If you specify `user`, it must match the username of the authenticated user.
- `group`, type string; if you specify `group`, it must match one of the groups of the authenticated user. `system:authenticated` matches all authenticated requests. `system:unauthenticated` matches all unauthenticated requests.
- `readonly`, type boolean, when true, means that the policy only applies to get, list, and watch operations.
- Resource-matching properties:
- `apiGroup`, type string; an API group, such as `extensions`. `*` matches all API groups.
@@ -115,8 +115,11 @@ The tuple of attributes is checked for a match against every policy in the
policy file. If at least one line matches the request attributes, then the
request is authorized (but may fail later validation).
To permit any user to do something, write a policy with the user property set to
`"*"`.
To permit any authenticated user to do something, write a policy with the
group property set to `"system:authenticated"`.
To permit any unauthenticated user to do something, write a policy with the
group property set to `"system:unauthenticated"`.
To permit a user to do anything, write a policy with the apiGroup, namespace,
resource, and nonResourcePath properties set to `"*"`.
@@ -165,7 +168,8 @@ up the verbosity:
5. Anyone can make read-only requests to all non-resource paths:
```json
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "*", "readonly": true, "nonResourcePath": "*"}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:authenticated", "readonly": true, "nonResourcePath": "*"}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
```
[Complete file example](http://releases.k8s.io/{{page.githubbranch}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
@@ -440,6 +444,28 @@ subjects:
name: system:serviceaccounts
```
For all authenticated users:
```yaml
subjects:
- kind: Group
name: system:authenticated
```
For all unauthenticated users:
```yaml
subjects:
- kind: Group
name: system:unauthenticated
```
For all users:
```yaml
subjects:
- kind: Group
name: system:authenticated
- kind: Group
name: system:unauthenticated
## Webhook Mode
When specified, mode `Webhook` causes Kubernetes to query an outside REST
@@ -504,7 +530,7 @@ An example request body:
"resourceAttributes": {
"namespace": "kittensandponies",
"verb": "GET",
"group": "*",
"group": "unicorn.example.org",
"resource": "pods"
},
"user": "jane",
@@ -627,7 +653,7 @@ __EOF__
--- snip lots of output ---
I0913 08:12:31.362873 27425 request.go:908] Response Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1beta1","metadata":{"creationTimestamp":null},"spec":{"resourceAttributes":{"namespace":"kittensandponies","verb":"GET","group":"*","resource":"pods"},"user":"jane","group":["group1","group2"]},"status":{"allowed":true}}
I0913 08:12:31.362873 27425 request.go:908] Response Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1beta1","metadata":{"creationTimestamp":null},"spec":{"resourceAttributes":{"namespace":"kittensandponies","verb":"GET","group":"unicorn.example.org","resource":"pods"},"user":"jane","group":["group1","group2"]},"status":{"allowed":true}}
subjectaccessreview "" created
```
docs/admin/cluster-components.md
+1 -1
View File
@@ -107,7 +107,7 @@ the Kubernetes runtime environment.
or via local configuration file) and:
* Mounts the pod's required volumes
* Downloads the pod's secrets
* Run the pod's containers via docker (or, experimentally, rkt).
* Runs the pod's containers via docker (or, experimentally, rkt).
* Periodically executes any requested container liveness probes.
* Reports the status of the pod back to the rest of the system, by creating a
"mirror pod" if necessary.
docs/admin/dns.md
+3 -3
View File
@@ -69,7 +69,7 @@ is no longer supported.
When enabled, pods are assigned a DNS A record in the form of `pod-ip-address.my-namespace.pod.cluster.local`.
For example, a pod with ip `1.2.3.4` in the namespace `default` with a DNS name of `cluster.local` would have an entry: `1-2-3-4.default.pod.cluster.local`.
For example, a pod with IP `1.2.3.4` in the namespace `default` with a DNS name of `cluster.local` would have an entry: `1-2-3-4.default.pod.cluster.local`.
#### A Records and hostname based on Pod's hostname and subdomain fields
@@ -280,7 +280,7 @@ If you see that no pod is running or that the pod has failed/completed, the DNS
Use `kubectl logs` command to see logs for the DNS daemons.
```
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kube-dns
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c healthz
```
@@ -308,7 +308,7 @@ If you have created the service or in the case it should be created by default b
#### Are DNS endpoints exposed?
You can verify that dns endpoints are exposed by using the `kubectl get endpoints` command.
You can verify that DNS endpoints are exposed by using the `kubectl get endpoints` command.
```
kubectl get ep kube-dns --namespace=kube-system
docs/admin/federation/index.md
+2 -2
View File
@@ -236,7 +236,7 @@ metadata:
name: kube-dns
namespace: kube-system
data:
federations: <federation-name>=<dns-domain-name>
federations: <federation-name>=<federation-domain-name>
```
where `<federation-name>` should be replaced by the name you want to give to your
@@ -249,7 +249,7 @@ http://kubernetes.io/docs/user-guide/configmap/.
### Kubernetes 1.4 and earlier: Setting federations flag on kube-dns-rc
If your cluster is running Kubernetes version 1.4 or earlier, you must to restart
If your cluster is running Kubernetes version 1.4 or earlier, you must restart
KubeDNS and pass it a `--federations` flag, which tells it about valid federation DNS hostnames.
The flag uses the following format:
docs/admin/garbage-collection.md
+1 -1
View File
@@ -24,7 +24,7 @@ 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 'Min Age' 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`.
docs/admin/ha-master-gce.md
+2 -2
View File
@@ -84,7 +84,7 @@ The following sample commands demonstrate this process:
$ KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
```
2. Add a new replica in place of the old one:
<ol start="2"><li>Add a new replica in place of the old one:</li></ol>
```shell
$ KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
@@ -102,7 +102,7 @@ A two-replica cluster is thus inferior, in terms of HA, to a single replica clus
* When you add a master replica, cluster state (etcd) is copied to a new instance.
If the cluster is large, it may take a long time to duplicate its state.
This operation may be speed up by migrating etcd data directory, as described [here](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration) here
This operation may be sped up by migrating etcd data directory, as described [here](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration)
(we are considering adding support for etcd data dir migration in future).
## Implementation notes
docs/admin/master-node-communication.md
+1 -1
View File
@@ -91,7 +91,7 @@ HTTP connections and are therefore neither authenticated nor encrypted. They
can be run over a secure HTTPS connection by prefixing `https:` to the node,
pod, or service name in the API URL, but they will not validate the certificate
provided by the HTTPS endpoint nor provide client credentials so while the
connection will by encrypted, it will not provide any guarantees of integrity.
connection will be encrypted, it will not provide any guarantees of integrity.
These connections **are not currently safe** to run over untrusted and/or
public networks.
docs/admin/multi-cluster.md
+2 -2
View File
@@ -8,7 +8,7 @@ You may want to set up multiple Kubernetes clusters, both to
have clusters in different regions to be nearer to your users, and to tolerate failures and/or invasive maintenance.
This document describes some of the issues to consider when making a decision about doing so.
If you decide to have multiple clusters, Kubernetes provides a way to [federate them](/docs/admin/federation/)
If you decide to have multiple clusters, Kubernetes provides a way to [federate them](/docs/admin/federation/).
## Scope of a single cluster
@@ -40,7 +40,7 @@ Reasons to have multiple clusters include:
## Selecting the right number of clusters
The selection of the number of Kubernetes clusters may be a relatively static choice, only revisited occasionally.
By contrast, the number of nodes in a cluster and the number of pods in a service may be change frequently according to
By contrast, the number of nodes in a cluster and the number of pods in a service may change frequently according to
load and growth.
To pick the number of clusters, first, decide which regions you need to be in to have adequate latency to all your end users, for services that will run
docs/admin/multiple-schedulers.md
+2
View File
@@ -107,6 +107,7 @@ scheduler as an annotation in that pod spec. Let's look at three examples.
```shell
kubectl create -f pod1.yaml
```
2. Pod spec with `default-scheduler` annotation
{% include code.html language="yaml" file="multiple-schedulers/pod2.yaml" ghlink="/docs/admin/multiple-schedulers/pod2.yaml" %}
@@ -120,6 +121,7 @@ scheduler as an annotation in that pod spec. Let's look at three examples.
```shell
kubectl create -f pod2.yaml
```
3. Pod spec with `my-scheduler` annotation
{% include code.html language="yaml" file="multiple-schedulers/pod3.yaml" ghlink="/docs/admin/multiple-schedulers/pod3.yaml" %}
docs/admin/multiple-zones.md
+10 -7
View File
@@ -51,7 +51,7 @@ admission controller automatically adds zone labels to them. The scheduler (via
`VolumeZonePredicate` predicate) will then ensure that pods that claim a
given volume are only placed into the same zone as that volume, as volumes
cannot be attached across zones.
## Limitations
There are some important limitations of the multizone support:
@@ -158,8 +158,7 @@ kubernetes-minion-wf8i Ready 2m beta.kubernetes.io
### Volume affinity
Create a volume (only PersistentVolumes are supported for zone
affinity), using the new dynamic volume creation:
Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
```json
kubectl create -f - <<EOF
@@ -186,10 +185,14 @@ kubectl create -f - <<EOF
EOF
```
The PV is also labeled with the zone & region it was created in. For
version 1.2, dynamic persistent volumes are always created in the zone
of the cluster master (here us-central1-a / us-west-2a); this will
be improved in a future version (issue [#23330](https://github.com/kubernetes/kubernetes/issues/23330).)
**NOTE:** For version 1.3+ Kubernetes will distribute dynamic PV claims across
the configured zones. For version 1.2, dynamic persistent volumes were
always created in the zone of the cluster master
(here us-central1-a / us-west-2a); that issue
([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
was addressed in 1.3+.
Now lets validate that Kubernetes automatically labeled the zone & region the PV was created in.
```shell
> kubectl get pv --show-labels
docs/admin/node-problem.md
+2 -2
View File
@@ -31,7 +31,7 @@ See more information
kernel log now. It doesn't support log tools like journald.
* The kernel issue detection of node problem detector has assumption on kernel
log format, now it only works on Ubuntu and Debian. However, it is easy to extend
log format, and now it only works on Ubuntu and Debian. However, it is easy to extend
it to [support other log format](/docs/admin/node-problem/#support-other-log-format).
## Enable/Disable in GCE cluster
@@ -194,7 +194,7 @@ and detects known kernel issues following predefined rules.
The Kernel Monitor matches kernel issues according to a set of predefined rule list in
[`config/kernel-monitor.json`](https://github.com/kubernetes/node-problem-detector/blob/v0.1/config/kernel-monitor.json).
The rule list is extensible, you can always extend it by [overwriting the
The rule list is extensible, and you can always extend it by [overwriting the
configuration](/docs/admin/node-problem/#overwrite-the-configuration).
### Add New NodeConditions
docs/admin/rescheduler.md
+2 -2
View File
@@ -31,10 +31,10 @@ To avoid situation when another pod is scheduled into the space prepared for the
the chosen node gets a temporary taint "CriticalAddonsOnly" before the eviction(s)
(see [more details](https://github.com/kubernetes/kubernetes/blob/master/docs/design/taint-toleration-dedicated.md)).
Each critical add-on has to tolerate it,
the other pods shouldn't tolerate the taint. The tain is removed once the add-on is successfully scheduled.
while the other pods shouldn't tolerate the taint. The taint is removed once the add-on is successfully scheduled.
*Warning:* currently there is no guarantee which node is chosen and which pods are being killed
in order to schedule critical pods, so if rescheduler is enabled you pods might be occasionally
in order to schedule critical pods, so if rescheduler is enabled your pods might be occasionally
killed for this purpose.
## Config
docs/admin/salt.md
+1 -1
View File
@@ -92,7 +92,7 @@ In addition, a cluster may be running a Debian based operating system or Red Hat
## Best Practices
1. When configuring default arguments for processes, it's best to avoid the use of EnvironmentFiles (Systemd in Red Hat environments) or init.d files (Debian distributions) to hold default values that should be common across operating system environments. This helps keep our Salt template files easy to understand for editors who may not be familiar with the particulars of each distribution.
When configuring default arguments for processes, it's best to avoid the use of EnvironmentFiles (Systemd in Red Hat environments) or init.d files (Debian distributions) to hold default values that should be common across operating system environments. This helps keep our Salt template files easy to understand for editors who may not be familiar with the particulars of each distribution.
## Future enhancements (Networking)
docs/admin/static-pods.md
+28 -28
View File
@@ -22,45 +22,45 @@ For example, this is how to start a simple web server as a static pod:
1. Choose a node where we want to run the static pod. In this example, it's `my-node1`.
```shell
[joe@host ~] $ ssh my-node1
```
```shell
[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`:
```shell
[root@my-node1 ~] $ mkdir /etc/kubernetes.d/
[root@my-node1 ~] $ cat <<EOF >/etc/kubernetes.d/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
```shell
[root@my-node1 ~] $ mkdir /etc/kubernetes.d/
[root@my-node1 ~] $ cat <<EOF >/etc/kubernetes.d/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
ports:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: tcp
EOF
```
containerPort: 80
protocol: TCP
EOF
```
2. 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/"
```
```conf
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
```
Instructions for other distributions or Kubernetes installations may vary.
Instructions for other distributions or Kubernetes installations may vary.
3. Restart kubelet. On Fedora, this is:
```shell
[root@my-node1 ~] $ systemctl restart kubelet
```
```shell
[root@my-node1 ~] $ systemctl restart kubelet
```
## Pods created via HTTP