kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge branch 'master' into fix-typos

pull/2036/head
Jared 2016-12-27 13:48:14 -08:00 committed by GitHub
parent 56aaad2e0b b0e69cf586
commit 5353c9aa90
15 changed files with 107 additions and 57 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
_data/reference.yml
View File

@ -54,9 +54,18 @@ toc:
- docs/user-guide/kubectl/kubectl_apply.md
- docs/user-guide/kubectl/kubectl_attach.md
- docs/user-guide/kubectl/kubectl_autoscale.md
- docs/user-guide/kubectl/kubectl_certificate.md
- docs/user-guide/kubectl/kubectl_certificate_approve.md
- docs/user-guide/kubectl/kubectl_certificate_deny.md
- docs/user-guide/kubectl/kubectl_cluster-info.md
- docs/user-guide/kubectl/kubectl_cluster-info_dump.md
- docs/user-guide/kubectl/kubectl_completion.md
- docs/user-guide/kubectl/kubectl_config.md
- docs/user-guide/kubectl/kubectl_config_current-context.md
- docs/user-guide/kubectl/kubectl_config_delete-cluster.md
- docs/user-guide/kubectl/kubectl_config_delete-context.md
- docs/user-guide/kubectl/kubectl_config_get-clusters.md
- docs/user-guide/kubectl/kubectl_config_get-contexts.md
- docs/user-guide/kubectl/kubectl_config_set-cluster.md
- docs/user-guide/kubectl/kubectl_config_set-context.md
- docs/user-guide/kubectl/kubectl_config_set-credentials.md
@ -66,13 +75,20 @@ toc:
- docs/user-guide/kubectl/kubectl_config_view.md
- docs/user-guide/kubectl/kubectl_convert.md
- docs/user-guide/kubectl/kubectl_cordon.md
- docs/user-guide/kubectl/kubectl_cp.md
- docs/user-guide/kubectl/kubectl_create.md
- docs/user-guide/kubectl/kubectl_create_configmap.md
- docs/user-guide/kubectl/kubectl_create_deployment.md
- docs/user-guide/kubectl/kubectl_create_namespace.md
- docs/user-guide/kubectl/kubectl_create_quota.md
- docs/user-guide/kubectl/kubectl_create_secret_docker-registry.md
- docs/user-guide/kubectl/kubectl_create_secret.md
- docs/user-guide/kubectl/kubectl_create_secret_generic.md
- docs/user-guide/kubectl/kubectl_create_secret_tls.md
- docs/user-guide/kubectl/kubectl_create_serviceaccount.md
- docs/user-guide/kubectl/kubectl_create_service_clusterip.md
- docs/user-guide/kubectl/kubectl_create_service_loadbalancer.md
- docs/user-guide/kubectl/kubectl_create_service_nodeport.md
- docs/user-guide/kubectl/kubectl_delete.md
- docs/user-guide/kubectl/kubectl_describe.md
- docs/user-guide/kubectl/kubectl_drain.md
@ -83,6 +99,7 @@ toc:
- docs/user-guide/kubectl/kubectl_get.md
- docs/user-guide/kubectl/kubectl_label.md
- docs/user-guide/kubectl/kubectl_logs.md
- docs/user-guide/kubectl/kubectl_options.md
- docs/user-guide/kubectl/kubectl_patch.md
- docs/user-guide/kubectl/kubectl_port-forward.md
- docs/user-guide/kubectl/kubectl_proxy.md
@ -92,9 +109,17 @@ toc:
- docs/user-guide/kubectl/kubectl_rollout_history.md
- docs/user-guide/kubectl/kubectl_rollout_pause.md
- docs/user-guide/kubectl/kubectl_rollout_resume.md
- docs/user-guide/kubectl/kubectl_rollout_status.md
- docs/user-guide/kubectl/kubectl_rollout_undo.md
- docs/user-guide/kubectl/kubectl_run.md
- docs/user-guide/kubectl/kubectl_scale.md
- docs/user-guide/kubectl/kubectl_set.md
- docs/user-guide/kubectl/kubectl_set_image.md
- docs/user-guide/kubectl/kubectl_set_resources.md
- docs/user-guide/kubectl/kubectl_taint.md
- docs/user-guide/kubectl/kubectl_top.md
- docs/user-guide/kubectl/kubectl_top_node.md
- docs/user-guide/kubectl/kubectl_top_pod.md
- docs/user-guide/kubectl/kubectl_uncordon.md
- docs/user-guide/kubectl/kubectl_version.md
- title: Superseded and Deprecated Commands

3
docs/tasks/administer-cluster/safely-drain-node.md
View File

@ -44,11 +44,13 @@ down its physical machine or, if running on a cloud platform, deleting its
virtual machine.
First, identify the name of the node you wish to drain. You can list all of the nodes in your cluster with
```shell
kubectl get nodes
```
Next, tell Kubernetes to drain the node:
```shell
kubectl drain <node name>
```
@ -56,6 +58,7 @@ kubectl drain <node name>
Once it returns (without giving an error), you can power down the node
(or equivalently, if on a cloud platform, delete the virtual machine backing the node).
If you leave the node in the cluster during the maintenance operation, you need to run
```shell
kubectl uncordon <node name>
```

4
docs/tutorials/stateful-application/basic-stateful-set.md
View File

@ -77,7 +77,7 @@ In the second terminal, use
Headless Service and StatefulSet defined in `web.yaml`.
```shell
kubectl create -f web.yml
kubectl create -f web.yaml
service "nginx" created
statefulset "web" created
```
@ -733,4 +733,4 @@ storage configuration, and provisioning method, to ensure that all storage is
reclaimed.
{% endcapture %}
{% include templates/tutorial.md %}
{% include templates/tutorial.md %}

2
docs/tutorials/stateless-application/run-stateless-application-deployment.md
View File

@ -101,7 +101,7 @@ should have four pods:
1. Verify that the Deployment has four pods:
kubectl get pods
kubectl get pods -l app=nginx
The output is similar to this:

2
docs/user-guide/connecting-applications.md
View File

@ -43,7 +43,7 @@ $ kubectl get pods -l run=my-nginx -o yaml | grep podIP
podIP: 10.244.2.5
```
You should be able to ssh into any node in your cluster and curl both IPs. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same containerPort and access them from any other pod or node in your cluster using IP. Like Docker, ports can still be published to the host node's interface(s), but the need for this is radically diminished because of the networking model.
You should be able to ssh into any node in your cluster and curl both IPs. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same containerPort and access them from any other pod or node in your cluster using IP. Like Docker, ports can still be published to the host node's interfaces, but the need for this is radically diminished because of the networking model.
You can read more about [how we achieve this](/docs/admin/networking/#how-to-achieve-this) if you're curious.

46
docs/user-guide/debugging-services.md
View File

@ -7,8 +7,8 @@ title: Debugging Services
---
An issue that comes up rather frequently for new installations of Kubernetes is
that `Services` are not working properly. You've run all your `Pod`s and
`Deployment`s, but you get no response when you try to access them.
that `Services` are not working properly. You've run all your `Pods` and
`Deployments`, but you get no response when you try to access them.
This document will hopefully help you to figure out what's going wrong.
* TOC
@ -17,7 +17,7 @@ This document will hopefully help you to figure out what's going wrong.
## Conventions
Throughout this doc you will see various commands that you can run. Some
commands need to be run within `Pod`, others on a Kubernetes `Node`, and others
commands need to be run within a `Pod`, others on a Kubernetes `Node`, and others
can run anywhere you have `kubectl` and credentials for the cluster. To make it
clear what is expected, this document will use the following conventions.
@ -71,7 +71,7 @@ $ kubectl exec -ti <POD-NAME> -c <CONTAINER-NAME> sh
## Setup
For the purposes of this walk-through, let's run some `Pod`s. Since you're
For the purposes of this walk-through, let's run some `Pods`. Since you're
probably debugging your own `Service` you can substitute your own details, or you
can follow along and get a second data point.
@ -109,7 +109,7 @@ spec:
protocol: TCP
```
Confirm your `Pod`s are running:
Confirm your `Pods` are running:
```shell
$ kubectl get pods -l app=hostnames
@ -196,7 +196,7 @@ Address: 10.0.1.175
```
If this fails, perhaps your `Pod` and `Service` are in different
`Namespace`s, try a namespace-qualified name:
`Namespaces`, try a namespace-qualified name:
```shell
u@pod$ nslookup hostnames.default
@ -207,7 +207,7 @@ Name: hostnames.default
Address: 10.0.1.175
```
If this works, you'll need to ensure that `Pod`s and `Service`s run in the same
If this works, you'll need to ensure that `Pods` and `Services` run in the same
`Namespace`. If this still fails, try a fully-qualified name:
```shell
@ -326,18 +326,18 @@ $ kubectl get service hostnames -o json
```
Is the port you are trying to access in `spec.ports[]`? Is the `targetPort`
correct for your `Pod`s? If you meant it to be a numeric port, is it a number
(9376) or a string "9376"? If you meant it to be a named port, do your `Pod`s
correct for your `Pods`? If you meant it to be a numeric port, is it a number
(9376) or a string "9376"? If you meant it to be a named port, do your `Pods`
expose a port with the same name? Is the port's `protocol` the same as the
`Pod`'s?
## Does the Service have any Endpoints?
If you got this far, we assume that you have confirmed that your `Service`
exists and resolves by DNS. Now let's check that the `Pod`s you ran are
exists and is resolved by DNS. Now let's check that the `Pods` you ran are
actually being selected by the `Service`.
Earlier we saw that the `Pod`s were running. We can re-check that:
Earlier we saw that the `Pods` were running. We can re-check that:
```shell
$ kubectl get pods -l app=hostnames
@ -347,7 +347,7 @@ hostnames-bvc05 1/1 Running 0 1h
hostnames-yp2kp 1/1 Running 0 1h
```
The "AGE" column says that these `Pod`s are about an hour old, which implies that
The "AGE" column says that these `Pods` are about an hour old, which implies that
they are running fine and not crashing.
The `-l app=hostnames` argument is a label selector - just like our `Service`
@ -360,16 +360,16 @@ NAME ENDPOINTS
hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376
```
This confirms that the control loop has found the correct `Pod`s for your
This confirms that the control loop has found the correct `Pods` for your
`Service`. If the `hostnames` row is blank, you should check that the
`spec.selector` field of your `Service` actually selects for `metadata.labels`
values on your `Pod`s.
values on your `Pods`.
## Are the Pods working?
At this point, we know that your `Service` exists and has selected your `Pod`s.
Let's check that the `Pod`s are actually working - we can bypass the `Service`
mechanism and go straight to the `Pod`s.
At this point, we know that your `Service` exists and has selected your `Pods`.
Let's check that the `Pods` are actually working - we can bypass the `Service`
mechanism and go straight to the `Pods`.
```shell
u@pod$ wget -qO- 10.244.0.5:9376
@ -384,19 +384,19 @@ hostnames-yp2kp
We expect each `Pod` in the `Endpoints` list to return its own hostname. If
this is not what happens (or whatever the correct behavior is for your own
`Pod`s), you should investigate what's happening there. You might find
`kubectl logs` to be useful or `kubectl exec` directly to your `Pod`s and check
`Pods`), you should investigate what's happening there. You might find
`kubectl logs` to be useful or `kubectl exec` directly to your `Pods` and check
service from there.
## Is the kube-proxy working?
If you get here, your `Service` is running, has `Endpoints`, and your `Pod`s
If you get here, your `Service` is running, has `Endpoints`, and your `Pods`
are actually serving. At this point, the whole `Service` proxy mechanism is
suspect. Let's confirm it, piece by piece.
### Is kube-proxy running?
Confirm that `kube-proxy` is running on your `Node`s. You should get something
Confirm that `kube-proxy` is running on your `Nodes`. You should get something
like the below:
```shell
@ -429,7 +429,7 @@ should double-check your `Node` configuration and installation steps.
### Is kube-proxy writing iptables rules?
One of the main responsibilities of `kube-proxy` is to write the `iptables`
rules which implement `Service`s. Let's check that those rules are getting
rules which implement `Services`. Let's check that those rules are getting
written.
The kube-proxy can run in either "userspace" mode or "iptables" mode.
@ -620,7 +620,7 @@ UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1
## Seek help
If you get this far, something very strange is happening. Your `Service` is
running, has `Endpoints`, and your `Pod`s are actually serving. You have DNS
running, has `Endpoints`, and your `Pods` are actually serving. You have DNS
working, `iptables` rules installed, and `kube-proxy` does not seem to be
misbehaving. And yet your `Service` is not working. You should probably let
us know, so we can help investigate!

4
docs/user-guide/kubectl/kubectl_drain.md
View File

@ -11,13 +11,13 @@ 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. 'drain' evicts the pods if the APIServer supports eviction (http://kubernetes.io/docs/admin/disruptions/). Otherwise, it will use normal DELETE to delete the pods. The 'drain' evicts or deletes all pods except mirror pods (which cannot be deleted through the API server). If there are DaemonSet-managed pods, drain will not proceed without --ignore-daemonsets, and regardless it will not delete any DaemonSet-managed pods, because those pods would be immediately replaced by the DaemonSet controller, which ignores unschedulable markings. If there are any pods that are neither mirror pods nor managed by ReplicationController, ReplicaSet, DaemonSet, StatefulSet or Job, then drain will not delete any pods unless you use --force.
The given node will be marked unschedulable to prevent new pods from arriving. 'drain' evicts the pods if the APIServer supports [eviction](http://kubernetes.io/docs/admin/disruptions/). Otherwise, it will use normal DELETE to delete the pods. The 'drain' evicts or deletes all pods except mirror pods (which cannot be deleted through the API server). If there are DaemonSet-managed pods, drain will not proceed without --ignore-daemonsets, and regardless it will not delete any DaemonSet-managed pods, because those pods would be immediately replaced by the DaemonSet controller, which ignores unschedulable markings. If there are any pods that are neither mirror pods nor managed by ReplicationController, ReplicaSet, DaemonSet, StatefulSet or Job, then drain will not delete any pods unless you use --force.
'drain' waits for graceful termination. You should not operate on the machine until the command completes.
When you are ready to put the node back into service, use kubectl uncordon, which will make the node schedulable again.
! http://kubernetes.io/images/docs/kubectl_drain.svg
![Workflow](http://kubernetes.io/images/docs/kubectl_drain.svg)
```
kubectl drain NODE

9
docs/user-guide/kubectl/kubectl_top-node.md
View File

@ -1,9 +0,0 @@
---
---
This file is autogenerated, but we've stopped checking such files into the
repository to reduce the need for rebases. Please run hack/generate-docs.sh to
populate this file.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/user-guide/kubectl/kubectl_top-node.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

9
docs/user-guide/kubectl/kubectl_top-pod.md
View File

@ -1,9 +0,0 @@
---
---
This file is autogenerated, but we've stopped checking such files into the
repository to reduce the need for rebases. Please run hack/generate-docs.sh to
populate this file.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/user-guide/kubectl/kubectl_top-pod.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

2
docs/user-guide/managing-deployments.md
View File

@ -80,7 +80,7 @@ service "my-nginx-svc" deleted
Because `kubectl` outputs resource names in the same syntax it accepts, it's easy to chain operations using `$()` or `xargs`:
```shell
$ kubectl get $(k create -f docs/user-guide/nginx/ -o name | grep service)
$ kubectl get $(kubectl create -f docs/user-guide/nginx/ -o name | grep service)
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-nginx-svc 10.0.0.208 80/TCP 0s
```

26
docs/user-guide/persistent-volumes/index.md
View File

@ -70,7 +70,7 @@ When a user is done with their volume, they can delete the PVC objects from the
### 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.
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 deleting the associated storage asset in external infrastructure (such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume). Volumes that were dynamically provisioned are always deleted.
#### Recycling
@ -108,6 +108,7 @@ However, the particular path specified in the custom recycler pod template in th
* GCEPersistentDisk
* AWSElasticBlockStore
* AzureFile
* AzureDisk
* FC (Fibre Channel)
* NFS
* iSCSI
@ -170,6 +171,7 @@ In the CLI, the access modes are abbreviated to:
| :--- | :---: | :---: | :---: |
| AWSElasticBlockStore | x | - | - |
| AzureFile | x | x | x |
| AzureDisk | x | - | - |
| CephFS | x | x | x |
| Cinder | x | - | - |
| FC | x | x | - |
@ -199,9 +201,9 @@ Current recycling policies are:
* Retain -- manual reclamation
* Recycle -- basic scrub ("rm -rf /thevolume/*")
* Delete -- associated storage asset such as AWS EBS, GCE PD or OpenStack Cinder volume is deleted
* Delete -- associated storage asset such as AWS EBS, GCE PD, Azure Disk, or OpenStack Cinder volume is deleted
Currently, only NFS and HostPath support recycling. AWS EBS, GCE PD and Cinder volumes support deletion.
Currently, only NFS and HostPath support recycling. AWS EBS, GCE PD, Azure Disk, and Cinder volumes support deletion.
### Phase
@ -508,6 +510,24 @@ parameters:
* `quobyteConfig`: use the specified configuration to create the volume. You can create a new configuration or modify an existing one with the Web console or the quobyte CLI. Default is "BASE".
* `quobyteTenant`: use the specified tenant ID to create/delete the volume. This Quobyte tenant has to be already present in Quobyte. Default is "DEFAULT".
#### Azure Disk
```yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
name: slow
provisioner: kubernetes.io/azure-disk
parameters:
skuName: Standard_LRS
location: eastus
storageAccount: azure_storage_account_name
```
* `skuName`: Azure storage account Sku tier. Default is empty.
* `location`: Azure storage account location. Default is empty.
* `storageAccount`: Azure storage account name. If storage account is not provided, all storage accounts associated with the resource group are searched to find one that matches `skuName` and `location`. If storage account is provided, `skuName` and `location` are ignored.
## Writing Portable Configuration

2
docs/user-guide/simple-nginx.md
View File

@ -14,7 +14,7 @@ From this point onwards, it is assumed that `kubectl` is on your path from one o
The [`kubectl run`](/docs/user-guide/kubectl/kubectl_run) line below will create a [`Deployment`](/docs/user-guide/deployments) named `my-nginx`, and
two [nginx](https://registry.hub.docker.com/_/nginx/) [pods](/docs/user-guide/pods) listening on port 80. The `Deployment` will ensure that there are
always exactly two pod running as specified in its spec.
always exactly two pods running as specified in its spec.
```shell
kubectl run my-nginx --image=nginx --replicas=2 --port=80

2
docs/whatisk8s.md
View File

@ -106,7 +106,7 @@ Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) syst
* Kubernetes does not provide nor mandate a comprehensive application configuration language/system (e.g., [jsonnet](https://github.com/google/jsonnet)).
* Kubernetes does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems.
On the other hand, a number of PaaS systems run *on* Kubernetes, such as [Openshift](https://github.com/openshift/origin), [Deis](http://deis.io/), and [Eldarion Cloud](http://eldarion.cloud/). You could also roll your own custom PaaS, integrate with a CI system of your choice, or get along just fine with just Kubernetes: bring your container images and deploy them on Kubernetes.
On the other hand, a number of PaaS systems run *on* Kubernetes, such as [Openshift](https://github.com/openshift/origin), [Deis](http://deis.io/), and [Eldarion](http://eldarion.cloud/). You could also roll your own custom PaaS, integrate with a CI system of your choice, or get along just fine with just Kubernetes: bring your container images and deploy them on Kubernetes.
Since Kubernetes operates at the application level rather than at just the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, logging, monitoring, etc. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable.

21
staging-container/Dockerfile
View File

@ -1,13 +1,26 @@
FROM starefossen/ruby-node:2-4
FROM alpine:3.3
RUN gem install github-pages
RUN apk add --no-cache \
build-base \
ca-certificates \
libffi-dev \
nodejs \
ruby-dev \
ruby-nokogiri \
zlib-dev
RUN gem install \
bundler \
github-pages \
io-console \
--no-rdoc --no-ri
VOLUME /k8sdocs
EXPOSE 4000
COPY start.sh /start.sh
WORKDIR /k8sdocs
CMD bundle && jekyll clean && jekyll serve -H 0.0.0.0 -P 4000
CMD [ "/start.sh" ]
# For instructions, see http://kubernetes.io/editdocs/

7
staging-container/start.sh Executable file
View File

@ -0,0 +1,7 @@
#!/bin/sh
set -e
set -x
bundle
bundle exec jekyll clean
bundle exec jekyll serve -H 0.0.0.0 -P 4000