Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.8
* '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:
@@ -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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user