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

Merge remote-tracking branch 'origin/master'

Browse Source
This commit is contained in:
scotty
2016-09-26 14:24:48 -07:00
parent ffc513d5b1 a581b8087e
commit 16d8224a51
20 changed files with 123 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+1 -1
View File
@@ -67,7 +67,7 @@ Your copy of the site will then be viewable at: [http://localhost:4000](http://l
## GitHub help
If you're a bit rusty with git/GitHub, you might wanna read
If you're a bit rusty with git/GitHub, you might want to read
[this](http://readwrite.com/2013/10/02/github-for-beginners-part-2) for a refresher.
## Common Tasks
docs/admin/authentication.md
+1 -1
View File
@@ -228,7 +228,7 @@ it must be an array of strings.
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)).
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 CloudFoundry [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.
docs/admin/authorization.md
+63
View File
@@ -323,6 +323,69 @@ roleRef:
apiVersion: rbac.authorization.k8s.io/v1alpha1
```
### Referring to Subjects
RoleBindings and ClusterRoleBindings bind "subjects" to "roles".
Subjects can be groups, users or service accounts.
Users are represented by strings. These can be plain usernames, like
"alice", or email style names, like "bob@example.com", or numeric ids
as string. It is up to the Kubernetes admin to configure
the [authentication modules](/doc/admin/authentication/) to produce
usernames in the desired format. The RBAC authorization system does
not require any particular format. However, the prefix `system:` is
reserved for Kubernetes system use, and so the admin should ensure
usernames should not contain this prefix by accident.
Groups information in Kubernetes is currently provided by the Authenticator
modules. (In the future we may add a separate way for the RBAC Authorizer
to query groups information for users.) Groups, like users, are represented
by a string, and that string has no format requirements, other than that the
prefix `system:` is reserved.
Service Accounts have usernames with the `system:` prefix and belong
to groups with the `system:` prefix.
#### Role Binding Examples
Only the `subjects` section of a RoleBinding object shown in the following examples.
For a user called `alice@example.com`, specify
```yaml
subjects:
- kind: User
name: "alice@example.com"
```
For a group called `frontend-admins`, specify:
```yaml
subjects:
- kind: Group
name: "frontend-admins"
```
For the default service account in the kube-system namespace:
```yaml
subjects:
- kind: ServiceAccount
name: default
namespace: kube-system
```
For all service accounts in the `qa` namespace:
```yaml
subjects:
- kind: Group
name: system:serviceaccounts:qa
```
For all service accounts everywhere:
```yaml
subjects:
- kind: Group
name: system:serviceaccounts
```
### Privilege Escalation Prevention and Bootstrapping
The `rbac.authorization.k8s.io` API group inherently attempts to prevent users
docs/admin/cluster-management.md
+1 -1
View File
@@ -84,7 +84,7 @@ no node that has enough free capacity (or doesn't match other pod requirements)
to wait until some pods are terminated or a new node is added.
Cluster autoscaler looks for the pods that cannot be scheduled and checks if adding a new node, similar
to the other in the cluster, would help. If yes, then it resizes the cluster to accomodate the waiting pods.
to the other in the cluster, would help. If yes, then it resizes the cluster to accommodate the waiting pods.
Cluster autoscaler also scales down the cluster if it notices that some node is not needed anymore for
an extended period of time (10min but it may change in the future).
docs/admin/garbage-collection.md
+1 -1
View File
@@ -52,5 +52,5 @@ Containers can potentially be garbage collected before their usefulness has expi
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
retained per expected container. A higher value for `maximum-dead-containers` is also recommended for a
similiar reason.
similar reason.
See [this issue](https://github.com/kubernetes/kubernetes/issues/13287) for more details.
docs/admin/multiple-zones.md
+1 -1
View File
@@ -39,7 +39,7 @@ or service across nodes in a single-zone cluster (to reduce the impact of
failures.) With multiple-zone clusters, this spreading behaviour is
extended across zones (to reduce the impact of zone failures.) (This is
achieved via `SelectorSpreadPriority`). This is a best-effort
placement, and so if the zones in your cluster are heterogenous
placement, and so if the zones in your cluster are heterogeneous
(e.g. different numbers of nodes, different types of nodes, or
different pod resource requirements), this might prevent perfectly
even spreading of your pods across zones. If desired, you can use
docs/getting-started-guides/fedora/flannel_multi_node_cluster.md
+1 -1
View File
@@ -18,7 +18,7 @@ You need 2 or more machines with Fedora installed.
**Perform following commands on the Kubernetes master**
* Configure flannel by creating a `flannel-config.json` in your current directory on fed-master. flannel provides udp and vxlan among other overlay networking backend options. In this guide, we choose kernel based vxlan backend. The contents of the json are:
* Configure flannel by creating a `flannel-config.json` in your current directory on fed-master. Flannel provides udp and vxlan among other overlay networking backend options. In this guide, we choose kernel based vxlan backend. The contents of the json are:
```json
{
docs/getting-started-guides/gce.md
+5 -5
View File
@@ -46,7 +46,7 @@ wget -q -O - https://get.k8s.io | bash
Once this command completes, you will have a master VM and four worker VMs, running as a Kubernetes cluster.
By default, some containers will already be running on your cluster. Containers like `kibana` and `elasticsearch` provide [logging](/docs/getting-started-guides/logging), while `heapster` provides [monitoring](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/README.md) services.
By default, some containers will already be running on your cluster. Containers like `fluentd` provide [logging](/docs/getting-started-guides/logging), while `heapster` provides [monitoring](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/README.md) services.
The script run by the commands above creates a cluster with the name/prefix "kubernetes". It defines one specific cluster config, so you can't run it more than once.
@@ -64,10 +64,10 @@ If you run into trouble, please see the section on [troubleshooting](/docs/getti
The next few steps will show you:
1. how to set up the command line client on your workstation to manage the cluster
1. examples of how to use the cluster
1. how to delete the cluster
1. how to start clusters with non-default options (like larger clusters)
1. How to set up the command line client on your workstation to manage the cluster
1. Examples of how to use the cluster
1. How to delete the cluster
1. How to start clusters with non-default options (like larger clusters)
### Installing the Kubernetes command line tools on your workstation
docs/getting-started-guides/rackspace.md
+1 -1
View File
@@ -62,7 +62,7 @@ There is a specific `cluster/rackspace` directory with the scripts for the follo
## Network Design
- eth0 - Public Interface used for servers/containers to reach the internet
- eth1 - ServiceNet - Intra-cluster communication (k8s, etcd, etc) communicate via this interface. The `cloud-config` files use the special CoreOS identifier `$private_ipv4` to configure the services.
- eth1 - ServiceNet - Intra-cluster communication (k8s, etcd, etc.) communicate via this interface. The `cloud-config` files use the special CoreOS identifier `$private_ipv4` to configure the services.
- eth2 - Cloud Network - Used for k8s pods to communicate with one another. The proxy service will pass traffic via this interface.
## Support Level
docs/getting-started-guides/scratch.md
+4 -4
View File
@@ -72,7 +72,7 @@ accomplished in two ways:
pod network through traffic encapsulation (e.g vxlan).
- Encapsulation reduces performance, though exactly how much depends on your solution.
- **Without an overlay network**
- Configure the underlying network fabric (switches, routers, etc) to be aware of pod IP addresses.
- Configure the underlying network fabric (switches, routers, etc.) to be aware of pod IP addresses.
- This does not require the encapsulation provided by an overlay, and so can achieve
better performance.
@@ -514,9 +514,9 @@ availability.
To run an etcd instance:
1. copy `cluster/saltbase/salt/etcd/etcd.manifest`
1. make any modifications needed
1. start the pod by putting it into the kubelet manifest directory
1. Copy `cluster/saltbase/salt/etcd/etcd.manifest`
1. Make any modifications needed
1. Start the pod by putting it into the kubelet manifest directory
### Apiserver, Controller Manager, and Scheduler
docs/hellonode.md
+1 -1
View File
@@ -117,7 +117,7 @@ curl http://localhost:8080
You should see `Hello World!`
**Note:** *If you recieve a `Connection refused` message from Docker for Mac, ensure you are using the latest version of Docker (1.12 or later). Alternatively, if you are using Docker Toolbox on OSX, make sure you are using the VM's IP and not localhost:*
**Note:** *If you receive a `Connection refused` message from Docker for Mac, ensure you are using the latest version of Docker (1.12 or later). Alternatively, if you are using Docker Toolbox on OSX, make sure you are using the VM's IP and not localhost:*
```shell
curl "http://$(docker-machine ip YOUR-VM-MACHINE-NAME):8080"
docs/templatedemos/filledout.md
+2 -2
View File
@@ -42,7 +42,7 @@ kubectl get pod <name>
| Return Value | Description |
|--------------|-------------|
| `READY` | Describes the number of containers that are ready to recieve traffic. |
| `READY` | Describes the number of containers that are ready to receive traffic. |
| `STATUS` | A value from the `PodPhase` enum describing the current status of the pod. Can be `Running`, `Pending`, `Succeeded`, `Failed`, and `Unknown`. |
TODO: Link to refpage for `kubectl get pod`
@@ -77,4 +77,4 @@ YAML EXAMPLE HERE
{% endcapture %}
{% include templates/concept-overview.md %}
{% include templates/concept-overview.md %}
docs/user-guide/accessing-the-cluster.md
+25 -3
View File
@@ -69,9 +69,9 @@ $ curl http://localhost:8080/api/
}
```
#### Without kubectl proxy
#### Without kubectl proxy (before v1.3.x)
It is also possible to avoid using kubectl proxy by passing an authentication token
It is possible to avoid using kubectl proxy by passing an authentication token
directly to the apiserver, like this:
```shell
@@ -85,7 +85,29 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
}
```
The above example uses the `--insecure` flag. This leaves it subject to MITM
#### Without kubectl proxy (post v1.3.x)
In Kubernetes version 1.3 or later, `kubectl config view` no longer displays the token. Use `kubectl describe secret...` to get the token for the default service account, like this:
``` shell
$ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d '\t')
$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
{
"kind": "APIVersions",
"versions": [
"v1"
],
"serverAddressByClientCIDRs": [
{
"clientCIDR": "0.0.0.0/0",
"serverAddress": "10.0.1.149:443"
}
]
}
```
The above examples use the `--insecure` flag. This leaves it subject to MITM
attacks. When kubectl accesses the cluster it uses a stored root certificate
and client certificates to access the server. (These are installed in the
`~/.kube` directory). Since cluster certificates are typically self-signed, it
docs/user-guide/federation/federated-services.md
+3 -3
View File
@@ -40,9 +40,9 @@ API for traditional Kubernetes Services.
Once created, the Federated Service automatically:
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
3. manages a set of DNS records in a public DNS provider (like Google Cloud DNS, or AWS Route 53), thus ensuring that clients
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
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,
availability zone or regional outages.
docs/user-guide/images.md
+4 -4
View File
@@ -118,12 +118,12 @@ in the `$HOME` of user `root` on a kubelet, then docker will use it.
Here are the recommended steps to configuring your nodes to use a private registry. In this
example, run these on your desktop/laptop:
1. run `docker login [server]` for each set of credentials you want to use. This updates `$HOME/.docker/config.json`.
1. view `$HOME/.docker/config.json` in an editor to ensure it contains just the credentials you want to use.
1. get a list of your nodes, for example:
1. Run `docker login [server]` for each set of credentials you want to use. This updates `$HOME/.docker/config.json`.
1. View `$HOME/.docker/config.json` in an editor to ensure it contains just the credentials you want to use.
1. Get a list of your nodes, for example:
- if you want the names: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')`
- if you want to get the IPs: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')`
1. copy your local `.docker/config.json` to the home directory of root on each node.
1. Copy your local `.docker/config.json` to the home directory of root on each node.
- for example: `for n in $nodes; do scp ~/.docker/config.json root@$n:/root/.docker/config.json; done`
Verify by creating a pod that uses a private image, e.g.:
docs/user-guide/jobs.md
+1 -1
View File
@@ -157,7 +157,7 @@ parallelism, for a variety or reasons:
remaining completions. Higher values of `.spec.parallelism` are effectively ignored.
- For work queue jobs, no new pods are started after any pod has succeeded -- remaining pods are allowed to complete, however.
- If the controller has not had time to react.
- If the controller failed to create pods for any reason (lack of ResourceQuota, lack of permission, etc),
- If the controller failed to create pods for any reason (lack of ResourceQuota, lack of permission, etc.),
then there may be fewer pods than requested.
- The controller may throttle new pod creation due to excessive previous pod failures in the same Job.
- When a pod is gracefully shutdown, it make take time to stop.
docs/user-guide/jobs/expansions/index.md
+1 -1
View File
@@ -32,7 +32,7 @@ We also put the same label on the pod template so that we can check on all Pods
with a single command.
After the job is created, the system will add more labels that distinguish one Job's pods
from another Job's pods.
Note that the label key `jobgroup` is not special to Kubernetes. you can pick your own label scheme.
Note that the label key `jobgroup` is not special to Kubernetes. You can pick your own label scheme.
Next, expand the template into multiple files, one for each item to be processed.
docs/user-guide/petset/bootstrapping/index.md
+2 -2
View File
@@ -19,7 +19,7 @@ This example shows you how to "carry over" runtime state across Pet restart by s
### 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 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:
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 transferred 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 entire 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 `/lib`, all your `apt-gets` will fail because there are no system libraries
@@ -130,7 +130,7 @@ Here's a tiny peer finder helper script that handles peer discovery, [available
* A DNS domain
* An `on-start` script to run with the initial constituency of the given domain as input
* An `on-change` script to run everytime the constituency of the given domain changes
* An `on-change` script to run every time the constituency of the given domain changes
The role of the peer finder:
docs/user-guide/update-demo/index.md
+4 -11
View File
@@ -13,11 +13,11 @@ here](https://github.com/kubernetes/kubernetes.github.io/tree/{{page.docsbranch}
### Step Zero: Prerequisites
This example assumes that you have forked the repository and [turned up a Kubernetes cluster](/docs/getting-started-guides/):
This example assumes that you have forked the docs repository and [turned up a Kubernetes cluster](/docs/getting-started-guides/):
```shell
$ cd kubernetes
$ ./cluster/kube-up.sh
$ git clone -b {{page.docsbranch}} https://github.com/kubernetes/kubernetes.github.io
$ cd kubernetes.github.io
```
### Step One: Turn up the UX for the demo
@@ -81,14 +81,7 @@ This first stops the replication controller by turning the target number of repl
### Step Six: Cleanup
To turn down a Kubernetes cluster:
```shell
$ ./cluster/kube-down.sh
```
Kill the proxy running in the background:
After you are done running this demo make sure to kill it:
After you are done running this demo make sure to kill the proxy running in the background:
```shell
$ jobs
docs/user-guide/volumes.md
+1 -1
View File
@@ -502,7 +502,7 @@ See the [Quobyte example](https://github.com/kubernetes/kubernetes/tree/{{page.g
## Resources
The storage media (Disk, SSD, etc) of an `emptyDir` volume is determined by the
The storage media (Disk, SSD, etc.) of an `emptyDir` volume is determined by the
medium of the filesystem holding the kubelet root dir (typically
`/var/lib/kubelet`). There is no limit on how much space an `emptyDir` or
`hostPath` volume can consume, and no isolation between containers or between