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

Merge branch 'master' into release-1.12

Browse Source
This commit is contained in:
zacharysarah
2018-10-17 19:10:16 -07:00
parent 01677e2710 548b538f72
commit 9a2e390e59
558 changed files with 71868 additions and 2594 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
-8
View File
@@ -22,14 +22,6 @@ It does not mean that there is a file named `kubeconfig`.
{{% capture prerequisites %}}
You need to have the [`kubectl`](/docs/tasks/tools/install-kubectl/) command-line tool installed.
{{% /capture %}}
{{< toc >}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
content/en/docs/tasks/access-kubernetes-api/setup-extension-api-server.md
+2 -7
View File
@@ -16,15 +16,10 @@ Setting up an extension API server to work the aggregation layer allows the Kube
{{% capture prerequisites %}}
* You need to have a Kubernetes cluster running.
* You must [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) and enable the apiserver flags.
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* You must [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) and enable the apiserver flags.
{{% /capture %}}
{{% capture steps %}}
content/en/docs/tasks/administer-cluster/cluster-management.md
+2 -1
View File
@@ -73,6 +73,7 @@ Different providers, and tools, will manage upgrades differently. It is recomme
* [kops](https://github.com/kubernetes/kops)
* [kubespray](https://github.com/kubernetes-incubator/kubespray)
* [CoreOS Tectonic](https://coreos.com/tectonic/docs/latest/admin/upgrade.html)
* [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html)
* ...
## Resizing a cluster
@@ -214,4 +215,4 @@ You can use `kubectl convert` command to convert config files between different
kubectl convert -f pod.yaml --output-version v1
```
For more options, please refer to the usage of [kubectl convert](/docs/user-guide/kubectl/{{page.version}}/#convert) command.
For more options, please refer to the usage of [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) command.
content/en/docs/tasks/administer-cluster/coredns.md
+15 -10
View File
@@ -7,7 +7,7 @@ content_template: templates/task
---
{{% capture overview %}}
This page describes the CoreDNS upgrade process and how to install kube-dns instead of CoreDNS.
This page describes the CoreDNS upgrade process and how to install CoreDNS instead of kube-dns.
{{% /capture %}}
{{% capture prerequisites %}}
@@ -29,15 +29,6 @@ deployment, or by using tools like kubeadm that will deploy and upgrade the clus
For manual deployment or replacement of kube-dns, see the documentation at the
[CoreDNS GitHub project.](https://github.com/coredns/deployment/tree/master/kubernetes)
## Installing CoreDNS with kubeadm
In Kubernetes 1.11, CoreDNS has graduated to General Availability (GA)
and is installed by default. To install kube-dns instead, set the `CoreDNS` feature gate
value to `false`:
```
kubeadm init --feature-gates=CoreDNS=false
```
## Upgrading an existing cluster with kubeadm
In Kubernetes version 1.10 and later, you can also move to CoreDNS when you use `kubeadm` to upgrade
@@ -58,6 +49,20 @@ customizations after the new ConfigMap is up and running.
If you are running CoreDNS in Kubernetes version 1.11 and later, during upgrade,
your existing Corefile will be retained.
## Installing kube-dns instead of CoreDNS with kubeadm
{{< note >}}
**Note:** In Kubernetes 1.11, CoreDNS has graduated to General Availability (GA)
and is installed by default.
{{< /note >}}
To install kube-dns instead, set the `CoreDNS` feature gate
value to `false`:
```
kubeadm init --feature-gates=CoreDNS=false
```
{{% /capture %}}
{{% capture whatsnext %}}
content/en/docs/tasks/administer-cluster/declare-network-policy.md
+9 -12
View File
@@ -9,22 +9,19 @@ content_template: templates/task
This document helps you get started using the Kubernetes [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) to declare network policies that govern how pods communicate with each other.
{{% /capture %}}
{{% capture prerequisites %}}
You'll need to have a Kubernetes cluster in place, with network policy support. There are a number of network providers that support NetworkPolicy, including:
* [Calico](/docs/tasks/configure-pod-container/calico-network-policy/)
* [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/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.
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
Make sure you've configured a network provider with network policy support. There are a number of network providers that support NetworkPolicy, including:
* [Calico](/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy/)
* [Cilium](/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/)
* [Kube-router](/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/)
* [Romana](/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
* [Weave Net](/docs/tasks/administer-cluster/network-policy-provider/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.
{{% /capture %}}
{{% capture steps %}}
content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md
+6 -4
View File
@@ -71,7 +71,8 @@ kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
Corefile: |
data:
Corefile: |
.:53 {
errors
health
@@ -94,7 +95,7 @@ The Corefile configuration includes the following [plugins](https://coredns.io/p
* [health](https://coredns.io/plugins/health/): Health of CoreDNS is reported to http://localhost:8080/health.
* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS will reply to DNS queries based on IP of the services and pods of Kubernetes. You can find more details [here](https://coredns.io/plugins/kubernetes/).
> The `pods insecure` option is provided for backward compatibility with kube-dns. You can use the `pod verified` option, which returns an A record only if there exists a pod in same namespace with matching IP. The `pods disabled` option can be used if you don't use pod records.
> The `pods insecure` option is provided for backward compatibility with kube-dns. You can use the `pods verified` option, which returns an A record only if there exists a pod in same namespace with matching IP. The `pods disabled` option can be used if you don't use pod records.
> `Upstream` is used for resolving services that point to external hosts (External Services).
@@ -139,7 +140,8 @@ kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
Corefile: |
data:
Corefile: |
.:53 {
errors
health
@@ -386,4 +388,4 @@ To migrate from kube-dns to CoreDNS, [a detailed blog](https://coredns.io/2018/0
A cluster administrator can also migrate using [the deploy script](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh), which will also help you translate the kube-dns configmap to the equivalent CoreDNS one.
## What's next
- [Debugging DNS Resolution](/docs/tasks/administer-cluster/dns-debugging-resolution/).
- [Debugging DNS Resolution](/docs/tasks/administer-cluster/dns-debugging-resolution/).
content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
-6
View File
@@ -18,12 +18,6 @@ Kubernetes cluster.
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## Determining whether DNS horizontal autoscaling is already enabled
content/en/docs/tasks/administer-cluster/encrypt-data.md
-10
View File
@@ -17,16 +17,6 @@ This page shows how to enable and configure encryption of secret data at rest.
* etcd v3 or later is required
* Encryption at rest is alpha in 1.7.0 which means it may change without notice. Users may be required to decrypt their data prior to upgrading to 1.8.0.
{{% /capture %}}
{{< toc >}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha.md
+7 -1
View File
@@ -150,6 +150,12 @@ Add an annotation for the cri-socket to the current node, for example to use doc
kubectl annotate node <nodename> kubeadm.alpha.kubernetes.io/cri-socket=/var/run/dockershim.sock
```
Apply the modified kubeadm-config on the node:
```shell
kubectl apply -f kubeadm-config-cm.yaml --force
```
Start the upgrade:
```shell
@@ -237,4 +243,4 @@ If the upgrade fails, see whether one of the following scenarios applies:
- If `kubeadm upgrade apply` on one of the secondary masters failed, the cluster is upgraded and working, but the secondary masters are in an undefined state. You need to investigate further and join the secondaries manually.
{{% /capture %}}
{{% /capture %}}
content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
+1 -1
View File
@@ -146,7 +146,7 @@ pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container i
## Attempt to create a Pod that does not meet the minimum memory request
Here's the configuration file for a Pod that has one Container. The Container specifies a
memory request of 200 MiB and a memory limit of 800 MiB.
memory request of 100 MiB and a memory limit of 800 MiB.
{{< codenew file="admin/resource/memory-constraints-pod-3.yaml" >}}
content/en/docs/tasks/administer-cluster/sysctl-cluster.md
+1 -1
View File
@@ -6,7 +6,7 @@ content_template: templates/task
---
{{% capture overview %}}
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
This document describes how to configure and use kernel parameters within a
Kubernetes cluster using the sysctl interface.
content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md
+6 -6
View File
@@ -29,9 +29,9 @@ Kubernetes cluster.
```shell
NAME STATUS ROLES AGE VERSION
worker0 Ready <none> 1d v1.11.1
worker1 Ready <none> 1d v1.11.1
worker2 Ready <none> 1d v1.11.1
worker0 Ready <none> 1d v1.12.0
worker1 Ready <none> 1d v1.12.0
worker2 Ready <none> 1d v1.12.0
```
1. Chose one of your nodes, and add a label to it:
@@ -51,9 +51,9 @@ Kubernetes cluster.
```shell
NAME STATUS ROLES AGE VERSION LABELS
worker0 Ready <none> 1d v1.11.1 ...,disktype=ssd,kubernetes.io/hostname=worker0
worker1 Ready <none> 1d v1.11.1 ...,kubernetes.io/hostname=worker1
worker2 Ready <none> 1d v1.11.1 ...,kubernetes.io/hostname=worker2
worker0 Ready <none> 1d v1.12.0 ...,disktype=ssd,kubernetes.io/hostname=worker0
worker1 Ready <none> 1d v1.12.0 ...,kubernetes.io/hostname=worker1
worker2 Ready <none> 1d v1.12.0 ...,kubernetes.io/hostname=worker2
```
In the preceding output, you can see that the `worker0` node has a
content/en/docs/tasks/debug-application-cluster/crictl.md
+1 -1
View File
@@ -65,7 +65,7 @@ debug: true
## Example crictl commands
The following examples show some `crictl` commands and and example output.
The following examples show some `crictl` commands and example output.
{{< warning >}}
**Warning:** If you use `crictl` to create pod sandboxes or containers on a running
content/en/docs/tasks/debug-application-cluster/debug-application-introspection.md
+4 -4
View File
@@ -258,10 +258,10 @@ Sometimes when debugging it can be useful to look at the status of a node -- for
```shell
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
kubernetes-node-861h NotReady <none> 1h v1.11.1
kubernetes-node-bols Ready <none> 1h v1.11.1
kubernetes-node-st6x Ready <none> 1h v1.11.1
kubernetes-node-unaj Ready <none> 1h v1.11.1
kubernetes-node-861h NotReady <none> 1h v1.12.0
kubernetes-node-bols Ready <none> 1h v1.12.0
kubernetes-node-st6x Ready <none> 1h v1.12.0
kubernetes-node-unaj Ready <none> 1h v1.12.0
```
```shell
content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+12 -6
View File
@@ -18,8 +18,6 @@ where bottlenecks can be removed to improve overall performance.
{{% /capture %}}
{{< toc >}}
{{% capture body %}}
In Kubernetes, application monitoring does not depend on a single monitoring
@@ -89,12 +87,20 @@ This video shows how to configure and run a Google Cloud Monitoring backed Heaps
{{< figure src="/images/docs/gcm.png" alt="Google Cloud Monitoring dashboard example" title="Google Cloud Monitoring dashboard example" caption="This dashboard shows cluster-wide resource usage." >}}
### Dynatrace Kubernetes monitoring
## CronJob monitoring
With [Dynatrace Kubernetes monitoring](https://www.dynatrace.com/technologies/kubernetes-monitoring/), you can monitor application and cluster health in highly-dynamic Kubernetes environments.
### Kubernetes Job Monitor
Dynatrace automatically discovers all containers running on Kubernetes and presents you with a real-time view of all the connections between your containerized processes, hosts, and cloud instances. Dynatrace includes root cause analysis and the ability to replay problems to see how they evolved over time.
With the [Kubernetes Job Monitor](https://github.com/pietervogelaar/kubernetes-job-monitor) dashboard a Cluster Administrator can see which jobs are running and view the status of completed jobs.
{{< figure src="/images/docs/dynatrace.png" alt="Dynatrace Kubernetes monitoring dashboard example" title="Dynatrace Kubernetes monitoring dashboard example" caption="This dashboard shows a Node overview." >}}
### New Relic Kubernetes monitoring integration
[New Relic Kubernetes](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration) integration provides increased visibility into the performance of your Kubernetes environment. New Relic's Kubernetes integration instruments the container orchestration layer by reporting metrics from Kubernetes objects. The integration gives you insight into your Kubernetes nodes, namespaces, deployments, replica sets, pods, and containers.
Marquee capabilities:
View your data in pre-built dashboards for immediate insight into your Kubernetes environment.
Create your own custom queries and charts in Insights from automatically reported data.
Create alert conditions on Kubernetes data.
Learn more on this [page](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration).
{{% /capture %}}
content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
+1 -2
View File
@@ -191,7 +191,7 @@ I am a plugin with a dash in my name
#### Name conflicts and overshadowing
It can be possible to have multiple plugins with the same filename in different locations throughout your PATH.
It is possible to have multiple plugins with the same filename in different locations throughout your PATH.
For example, given a PATH with the following value: `PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins`, a copy of plugin `kubectl-foo` could exist in `/usr/local/bin/plugins` and `/usr/local/bin/moreplugins`,
such that the output of the `kubectl plugin list` command is:
@@ -276,4 +276,3 @@ See the [Sample CLI Plugin](https://github.com/kubernetes/sample-cli-plugin) for
{{% /capture %}}
content/en/docs/tasks/inject-data-application/define-environment-variable-container.md
+1 -1
View File
@@ -113,7 +113,7 @@ Upon creation, the command `echo Warm greetings to The Most Honorable Kubernetes
{{% capture whatsnext %}}
* Learn more about [environment variables](/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/).
* Learn more about [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
* Learn about [using secrets as environment variables](/docs/user-guide/secrets/#using-secrets-as-environment-variables).
* See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
+1 -1
View File
@@ -25,7 +25,7 @@ Pod fields and Container fields.
There are two ways to expose Pod and Container fields to a running Container:
* [Environment variables](/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/)
* [Environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)
* DownwardAPIVolumeFiles
Together, these two ways of exposing Pod and Container fields are called the
content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md
+19 -1
View File
@@ -130,6 +130,16 @@ A cron job config also needs a [`.spec` section](https://git.k8s.io/community/co
The `.spec.schedule` is a required field of the `.spec`.
It takes a [Cron](https://en.wikipedia.org/wiki/Cron) format string, such as `0 * * * *` or `@hourly`, as schedule time of its jobs to be created and executed.
The format also includes extended `vixie cron` step values. As explained in the [FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29):
> Step values can be used in conjunction with ranges. Following a range
> with ``/<number>'' specifies skips of the number's value through the
> range. For example, ``0-23/2'' can be used in the hours field to specify
> command execution every other hour (the alternative in the V7 standard is
> ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps are also permitted after an
> asterisk, so if you want to say ``every two hours'', just use ``*/2''.
**Note:** The question mark (`?`) in the schedule has the same meaning as an asterisk `*`, that is, it stands for any of available value for a given field.
### Job Template
@@ -146,7 +156,15 @@ After the deadline, the cron job does not start the job.
Jobs that do not meet their deadline in this way count as failed jobs.
If this field is not specified, the jobs have no deadline.
It is important to note that if the `.spec.startingDeadlineSeconds` field is set (not nil), the CronJob controller counts how many missed jobs occurred from the value of `.spec.startingDeadlineSeconds` until now. For example, if it is set to `200`, it counts how many missed schedules occurred in the last 200 seconds. If there were more than 100 missed schedules, the cronjob would not be scheduled.
The CronJob controller counts how many missed schedules happen for a cron job. If there are more than 100 missed
schedules, the cron job is no longer scheduled. When `.spec.startingDeadlineSeconds` is not set, the CronJob
controller counts missed schedules from `status.lastScheduleTime` until now. For example, one cron job is
supposed to run every minute, the `status.lastScheduleTime` of the cronjob is 5:00am, but now it's 7:00am.
That means 120 schedules were missed, so the cron job is no longer scheduled. If the `.spec.startingDeadlineSeconds`
field is set (not null), the CronJob controller counts how many missed jobs occurred from the value of
`.spec.startingDeadlineSeconds` until now. For example, if it is set to `200`, it counts how many missed
schedules occurred in the last 200 seconds. In that case, if there were more than 100 missed schedules in the
last 200 seconds, the cron job is no longer scheduled.
### Concurrency Policy
content/en/docs/tasks/manage-daemon/update-daemon-set.md
+3 -3
View File
@@ -25,12 +25,12 @@ This page shows how to perform a rolling update on a DaemonSet.
DaemonSet has two update strategy types:
* OnDelete: This is the default update strategy for backward-compatibility. With
`OnDelete` update strategy, after you update a DaemonSet template, new
* OnDelete: With `OnDelete` update strategy, after you update a DaemonSet template, new
DaemonSet pods will *only* be created when you manually delete old DaemonSet
pods. This is the same behavior of DaemonSet in Kubernetes version 1.5 or
before.
* RollingUpdate: With `RollingUpdate` update strategy, after you update a
* RollingUpdate: This is the default update strategy.
With `RollingUpdate` update strategy, after you update a
DaemonSet template, old DaemonSet pods will be killed, and new DaemonSet pods
will be created automatically, in a controlled fashion.
content/en/docs/tasks/manage-gpus/scheduling-gpus.md
+30 -8
View File
@@ -7,10 +7,13 @@ title: Schedule GPUs
{{% capture overview %}}
Kubernetes includes **experimental** support for managing NVIDIA GPUs spread
Kubernetes includes **experimental** support for managing AMD and NVIDIA GPUs spread
across nodes. The support for NVIDIA GPUs was added in v1.6 and has gone through
multiple backwards incompatible iterations. This page describes how users can
consume GPUs across different Kubernetes versions and the current limitations.
multiple backwards incompatible iterations. The support for AMD GPUs was added in
v1.9 via [device plugin](#deploying-amd-gpu-device-plugin).
This page describes how users can consume GPUs across different Kubernetes versions
and the current limitations.
{{% /capture %}}
@@ -28,14 +31,15 @@ feature gate has to be explicitly set to true across the system:
`--feature-gates="DevicePlugins=true"`. This is no longer required starting
from 1.10.
Then you have to install NVIDIA drivers on the nodes and run an NVIDIA GPU device
plugin ([see below](#deploying-nvidia-gpu-device-plugin)).
Then you have to install GPU drivers from the corresponding vendor on the nodes
and run the corresponding device plugin from the GPU vendor
([AMD](#deploying-amd-gpu-device-plugin), [NVIDIA](#deploying-nvidia-gpu-device-plugin)).
When the above conditions are true, Kubernetes will expose `nvidia.com/gpu` as
a schedulable resource.
When the above conditions are true, Kubernetes will expose `nvidia.com/gpu` or
`amd.com/gpu` as a schedulable resource.
You can consume these GPUs from your containers by requesting
`nvidia.com/gpu` just like you request `cpu` or `memory`.
`<vendor>.com/gpu` just like you request `cpu` or `memory`.
However, there are some limitations in how you specify the resource requirements
when using GPUs:
@@ -67,6 +71,24 @@ spec:
nvidia.com/gpu: 1 # requesting 1 GPU
```
### Deploying AMD GPU device plugin
The [official AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
has the following requirements:
- Kubernetes nodes have to be pre-installed with AMD GPU Linux driver.
To deploy the AMD device plugin once your cluster is running and the above
requirements are satisfied:
```
# For Kubernetes v1.9
kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/r1.9/k8s-ds-amdgpu-dp.yaml
# For Kubernetes v1.10
kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/r1.10/k8s-ds-amdgpu-dp.yaml
```
Report issues with this device plugin to [RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin).
### Deploying NVIDIA GPU device plugin
There are currently two device plugin implementations for NVIDIA GPUs:
content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+2 -2
View File
@@ -440,7 +440,7 @@ the quantity `10500m` would be written as `10.5` in decimal notation. The metri
will return whole numbers without a suffix when possible, and will generally return
quantities in milli-units otherwise. This means you might see your metric value fluctuate
between `1` and `1500m`, or `1` and `1.5` when written in decimal notation. See the
[glossary entry on quantities](/docs/reference/glossary/quantity.md) for more information.
[glossary entry on quantities](/docs/reference/glossary?core-object=true#term-quantity) for more information.
## Appendix: Other possible scenarios
@@ -458,4 +458,4 @@ $ kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
horizontalpodautoscaler.autoscaling/php-apache created
```
{{% /capture %}}
{{% /capture %}}
content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
+8 -8
View File
@@ -64,7 +64,7 @@ or the custom metrics API (for all other metrics).
except that it works with raw values, not utilization values.
* For object metrics and external metrics, a single metric is fetched, which describes
the object in question. This metric is compared compared to the target
the object in question. This metric is compared to the target
value, to produce a ratio as above. In the `autoscaling/v2beta2` API
version, this value can optionally be divided by the number of pods before the
comparison is made.
@@ -99,7 +99,7 @@ desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricVal
For example, if the current metric value is `200m`, and the desired value
is `100m`, the number of replicas will be doubled, since `200.0 / 100.0 ==
2.0` If the the current value is instead `50m`, we'll halve the number of
2.0` If the current value is instead `50m`, we'll halve the number of
replicas, since `50.0 / 100.0 == 0.5`. We'll skip scaling if the ratio is
sufficiently close to 1.0 (within a globally-configurable tolerance, from
the `--horizontal-pod-autoscaler-tolerance` flag, which defaults to 0.1).
@@ -122,7 +122,7 @@ became ready, that pod is set aside as well.
Due to technical constraints, the HorizontalPodAutoscaler controller
cannot exactly determine the first time a pod becomes ready when
determinining whether to set aside certain CPU metrics. Instead, it
determining whether to set aside certain CPU metrics. Instead, it
considers a Pod "not yet ready" if it's unready and transitioned to
unready within a short, configurable window of time since it started.
This value is configured with the `--horizontal-pod-autoscaler-initial-readiness-delay` flag, and its default is 30
@@ -139,9 +139,9 @@ conservatively, assuming those pods were consuming 100% of the desired
value in case of a scale down, and 0% in case of a scale up. This dampens
the magnitude of any potential scale.
Futhermore, if any not-yet-ready pods were present, and we would have
Furthermore, if any not-yet-ready pods were present, and we would have
scaled up without factoring in missing metrics or not-yet-ready pods, we
conservatively assume the non-yet-ready pods are consuming 0% of the
conservatively assume the not-yet-ready pods are consuming 0% of the
desired metric, further dampening the magnitude of a scale up.
After factoring in the not-yet-ready pods and missing metrics, we
@@ -161,9 +161,9 @@ into a desired replica count (e.g. due to an error fetching the metrics
from the metrics APIs), scaling is skipped.
Finally, just before HPA scales the target, the scale reccomendation is recorded. The
controller considers all reccomendations within a configurable window choosing the
controller considers all recommendations within a configurable window choosing the
highest recommendation from within that window. This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization-window` flag, which defaults to 5 minutes.
This means that scaledowns will occur gradually, smothing out the impact of rapidly
This means that scaledowns will occur gradually, smoothing out the impact of rapidly
fluctuating metric values.
## API Object
@@ -278,4 +278,4 @@ APIs, cluster administrators must ensure that:
* kubectl autoscale command: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
* Usage example of [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
{{% /capture %}}
{{% /capture %}}
content/en/docs/tasks/tls/certificate-rotation.md
+1 -1
View File
@@ -27,7 +27,7 @@ default, these certificates are issued with one year expiration so that they do
not need to be renewed too frequently.
Kubernetes 1.8 contains [kubelet certificate
rotation](/docs/tasks/administer-cluster/certificate-rotation/), a beta feature
rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), a beta feature
that will automatically generate a new key and request a new certificate from
the Kubernetes API as the current certificate approaches expiration. Once the
new certificate is available, it will be used for authenticating connections to
content/en/docs/tasks/tools/install-kubectl.md
-1
View File
@@ -28,7 +28,6 @@ Here are a few methods to install kubectl.
{{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}}
sudo apt-get update && sudo apt-get install -y apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
sudo touch /etc/apt/sources.list.d/kubernetes.list
echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubectl