* 'master' of https://github.com/kubernetes/kubernetes.github.io: (87 commits)
  fix envFrom in configmap
  Add link to example for CRDs (#5641)
  Fixed links to architecture.md and principles.md
  Polish AppArmor tutorial
  Remove dangling files related to apparmor
  fix the typo of serviceaccount (#5533)
  Correct setup link (#5634)
  relink the  persistent volume of petset (#5582)
  Updates to case study landing page (#5629)
  translate doc resource-quotas into chinese
  minor encoding fix for CN page
  fix typo
  concepts-overview-components+abac-fix
  concepts-overview-components-fix
  Update links to avoid redirects. (#5627)
  Update links to avoid redirects. (#5625)
  Fix 404s. (#5624)
  Fix 404s. (#5623)
  Edits cpu-constraint-namespace.md
  Fix index redirects (#5502)
  ...

# Conflicts:
#	_redirects
#	docs/concepts/storage/volumes.md
#	docs/concepts/workloads/controllers/daemonset.md
#	docs/concepts/workloads/controllers/petset.md
#	docs/concepts/workloads/controllers/statefulset.md
#	docs/tasks/run-application/run-single-instance-stateful-application.md
#	docs/tutorials/stateful-application/zookeeper.md
This commit is contained in:
Andrew Chen
2017-09-26 17:29:30 -07:00
126 changed files with 3823 additions and 1089 deletions
@@ -147,7 +147,7 @@ If the application is deployed as a Pod in the cluster, please refer to the [nex
To use [Python client](https://github.com/kubernetes-incubator/client-python), run the following command: `pip install kubernetes` See [Python Client Library page](https://github.com/kubernetes-incubator/client-python) for more installation options.
The Python client can use the same [kubeconfig file](/docs/user-guide/kubeconfig-file)
The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes-incubator/client-python/tree/master/examples/example1.py):
```python
@@ -15,7 +15,7 @@ This page shows how to use Calico for NetworkPolicy.
{% capture steps %}
## Deploying a cluster using Calico
You can deploy a cluster using Calico for network policy in the default [GCE deployment](/docs/getting-started-guides/gce) using the following set of commands:
You can deploy a cluster using Calico for network policy in the default [GCE deployment](/docs/getting-started-guides/gce/) using the following set of commands:
```shell
export NETWORK_POLICY_PROVIDER=calico
@@ -22,7 +22,7 @@ Depending on the installation method, your Kubernetes cluster may be deployed wi
an existing StorageClass that is marked as default. This default StorageClass
is then used to dynamically provision storage for PersistentVolumeClaims
that do not require any specific storage class. See
[PersistentVolumeClaim documentation](/docs/user-guide/persistent-volumes/#class-1)
[PersistentVolumeClaim documentation](/docs/concepts/storage/persistent-volumes/#class-1)
for details.
The pre-installed default StorageClass may not fit well with your expected workload;
@@ -68,7 +68,7 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
{% capture whatsnext %}
* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
* Learn more about [PersistentVolumeClaims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims).
* Learn more about [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
### Reference
@@ -184,7 +184,7 @@ etcd supports restoring from snapshots that are taken from an etcd process of th
Before starting the restore operation, a snapshot file must be present. It can either be a snapshot file from a previous backup operation, or from a remaining [data directory](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/configuration.md#--data-dir). `datadir` is located at `$DATA_DIR/member/snap/db`. For more information and examples on restoring a cluster from a snapshot file, see [etcd disaster recovery documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/recovery.md#restoring-a-cluster).
If the access URLs of the restored cluster is changed from the previous cluster, the Kubernetes API server must be reconfigured accordingly. In this case, restart Kubernetes API server with the flag `--etcd-servers=$NEW_ETCD_CLUSTER` instead of the flag `--etcd-servers=$OLD__ETCD_CLUSTER`. Replace `$NEW_ETCD_CLUSTER` and `$OLD__ETCD_CLUSTER` with the respective IP addresses. If a load balancer is used in front of an etcd cluster, you might need to update the load balancer instead.
If the access URLs of the restored cluster is changed from the previous cluster, the Kubernetes API server must be reconfigured accordingly. In this case, restart Kubernetes API server with the flag `--etcd-servers=$NEW_ETCD_CLUSTER` instead of the flag `--etcd-servers=$OLD_ETCD_CLUSTER`. Replace `$NEW_ETCD_CLUSTER` and `$OLD_ETCD_CLUSTER` with the respective IP addresses. If a load balancer is used in front of an etcd cluster, you might need to update the load balancer instead.
If the majority of etcd members have permanently failed, the etcd cluster is considered failed. In this scenario, Kubernetes cannot make any changes to its current state. Although the scheduled pods might continue to run, no new pods can be scheduled. In such cases, recover the etcd cluster and potentially reconfigure Kubernetes API server to fix the issue.
@@ -195,7 +195,7 @@ resources:
Because your Container did not specify its own CPU request and limit, it was given the
[default CPU request and limit](/docs/tasks/administer-cluster/cpu-default-namespace/)
from the LimitRange.
* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace)
At this point, your Container might be running or it might not be running. Recall that a prerequisite
for this task is that your Nodes have at least 1 CPU. If each of your Nodes has only
1 CPU, then there might not be enough allocatable CPU on any Node to accommodate a request
@@ -219,12 +219,12 @@ Pods that were created previously.
As a cluster administrator, you might want to impose restrictions on the CPU resources that Pods can use.
For example:
* Each Node in a cluster has 2 cpu. You do not want to accept any Pod that requests
more than 2 cpu, because no Node in the cluster can support the request.
* Each Node in a cluster has 2 CPU. You do not want to accept any Pod that requests
more than 2 CPU, because no Node in the cluster can support the request.
* A cluster is shared by your production and development departments.
You want to allow production workloads to consume up to 3 cpu, but you want development workloads to be limited
to 1 cpu. You create separate namespaces for production and development, and you apply CPU constraints to
You want to allow production workloads to consume up to 3 CPU, but you want development workloads to be limited
to 1 CPU. You create separate namespaces for production and development, and you apply CPU constraints to
each namespace.
## Clean up
@@ -15,7 +15,7 @@ You'll need to have a Kubernetes cluster in place, with network policy support.
* [Cilium](/docs/tasks/administer-cluster/cilium-network-policy/)
* [Kube-router](/docs/tasks/administer-cluster/kube-router-network-policy/)
* [Romana](/docs/tasks/configure-pod-container/romana-network-policy/)
* [Weave Net](/docs/tasks/configure-pod-container/weave-network-policy/)
* [Weave Net](/docs/tasks/administer-cluster/weave-network-policy/)
**Note**: The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
{% endcapture %}
@@ -49,7 +49,7 @@ container, and if users use the [node
allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) feature, out of resource decisions
are made local to the end user pod part of the cgroup hierarchy as well as the
root node. This
[script](/docs/concepts/cluster-administration/out-of-resource/memory-available.sh)
[script](/docs/tasks/administer-cluster/out-of-resource/memory-available.sh)
reproduces the same set of steps that the `kubelet` performs to calculate
`memory.available`. The `kubelet` excludes inactive_file (i.e. # of bytes of
file-backed memory on inactive LRU list) from its calculation as it assumes that
@@ -66,7 +66,7 @@ being terminated and recreated on other nodes. The out of the box roles represen
between flexibility and the common use cases, but more limited roles should be carefully reviewed
to prevent accidental escalation. You can make roles specific to your use case if the out-of-box ones don't meet your needs.
Consult the [authorization reference section](/docs/admin/authorization) for more information.
Consult the [authorization reference section](/docs/admin/authorization/) for more information.
## Controlling the capabilities of a workload or user at runtime
@@ -82,7 +82,7 @@ resources granted to a namespace. This is most often used to limit the amount of
or persistent disk a namespace can allocate, but can also control how many pods, services, or
volumes exist in each namespace.
[Limit ranges](/docs/admin/limitrange) restrict the maximum or minimum size of some of the
[Limit ranges](/docs/tasks/administer-cluster/memory-default-namespace/) restrict the maximum or minimum size of some of the
resources above, to prevent users from requesting unreasonably high or low values for commonly
reserved resources like memory, or to provide default limits when none are specified.