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

update with master content resolving merge conflicts

Browse Source
This commit is contained in:
MAKOSCAFEE
2019-06-19 19:10:18 +03:00
parent b42f019aae 42cbe1256e
commit 8781518d32
1439 changed files with 70927 additions and 43295 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/run-application/configure-pdb.md
+19 -23
View File
@@ -79,6 +79,22 @@ due to a voluntary disruption.
- Concern: Job needs to complete in case of voluntary disruption.
- Possible solution: Do not create a PDB. The Job controller will create a replacement pod.
### Rounding logic when specifying percentages
Values for `minAvailable` or `maxUnavailable` can be expressed as integers or as a percentage.
- When you specify an integer, it represents a number of Pods. For instance, if you set `minAvailable` to 10, then 10
Pods must always be available, even during a disruption.
- When you specify a percentage by setting the value to a string representation of a percentage (eg. `"50%"`), it represents a percentage of
total Pods. For instance, if you set `minUnavailable` to `"50%"`, then only 50% of the Pods can be unavailable during a
disruption.
When you specify the value as a percentage, it may not map to an exact number of Pods. For example, if you have 7 Pods and
you set `minAvailable` to `"50%"`, it's not immediately obvious whether that means 3 Pods or 4 Pods must be available.
Kubernetes rounds up to the nearest integer, so in this case, 4 Pods must be available. You can examine the
[code](https://github.com/kubernetes/kubernetes/blob/23be9587a0f8677eb8091464098881df939c44a9/pkg/controller/disruption/disruption.go#L539)
that controls this behavior.
## Specifying a PodDisruptionBudget
A `PodDisruptionBudget` has three fields:
@@ -137,31 +153,11 @@ You can find examples of pod disruption budgets defined below. They match pods w
Example PDB Using minAvailable:
```yaml
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: zookeeper
```
{{< codenew file="policy/zookeeper-pod-disruption-budget-minavailable.yaml" >}}
Example PDB Using maxUnavailable (Kubernetes 1.7 or higher):
```yaml
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
spec:
maxUnavailable: 1
selector:
matchLabels:
app: zookeeper
```
{{< codenew file="policy/zookeeper-pod-disruption-budget-maxunavailable.yaml" >}}
For example, if the above `zk-pdb` object selects the pods of a StatefulSet of size 3, both
specifications have the exact same meaning. The use of `maxUnavailable` is recommended as it
@@ -213,7 +209,7 @@ metadata:
creationTimestamp: 2017-08-28T02:38:26Z
generation: 1
name: zk-pdb
...
…
status:
currentHealthy: 3
desiredHealthy: 3
content/en/docs/tasks/run-application/delete-stateful-set.md
+1 -1
View File
@@ -12,7 +12,7 @@ weight: 60
{{% capture overview %}}
This task shows you how to delete a StatefulSet.
This task shows you how to delete a {{< glossary_tooltip term_id="StatefulSet" >}}.
{{% /capture %}}
content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
+2 -2
View File
@@ -10,7 +10,7 @@ weight: 70
---
{{% capture overview %}}
This page shows how to delete Pods which are part of a stateful set, and explains the considerations to keep in mind when doing so.
This page shows how to delete Pods which are part of a {{< glossary_tooltip text="stateful set" term_id="StatefulSet" >}}, and explains the considerations to keep in mind when doing so.
{{% /capture %}}
{{% capture prerequisites %}}
@@ -24,7 +24,7 @@ This page shows how to delete Pods which are part of a stateful set, and explain
## StatefulSet considerations
In normal operation of a StatefulSet, there is **never** a need to force delete a StatefulSet Pod. The StatefulSet controller is responsible for creating, scaling and deleting members of the StatefulSet. It tries to ensure that the specified number of Pods from ordinal 0 through N-1 are alive and ready. StatefulSet ensures that, at any time, there is at most one Pod with a given identity running in a cluster. This is referred to as *at most one* semantics provided by a StatefulSet.
In normal operation of a StatefulSet, there is **never** a need to force delete a StatefulSet Pod. The [StatefulSet controller](/docs/concepts/workloads/controllers/statefulset/) is responsible for creating, scaling and deleting members of the StatefulSet. It tries to ensure that the specified number of Pods from ordinal 0 through N-1 are alive and ready. StatefulSet ensures that, at any time, there is at most one Pod with a given identity running in a cluster. This is referred to as *at most one* semantics provided by a StatefulSet.
Manual force deletion should be undertaken with caution, as it has the potential to violate the at most one semantics inherent to StatefulSet. StatefulSets may be used to run distributed and clustered applications which have a need for a stable network identity and stable storage. These applications often have configuration which relies on an ensemble of a fixed number of members with fixed identities. Having multiple members with the same identity can be disastrous and may lead to data loss (e.g. split brain scenario in quorum-based systems).
content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+6 -6
View File
@@ -25,8 +25,8 @@ This document walks you through an example of enabling Horizontal Pod Autoscaler
This example requires a running Kubernetes cluster and kubectl, version 1.2 or later.
[metrics-server](https://github.com/kubernetes-incubator/metrics-server/) monitoring needs to be deployed in the cluster
to provide metrics via the resource metrics API, as Horizontal Pod Autoscaler uses this API to collect metrics. The instructions for deploying this are on the GitHub repository of [metrics-server](https://github.com/kubernetes-incubator/metrics-server/), if you followed [getting started on GCE guide](/docs/setup/turnkey/gce/),
metrics-server monitoring will be turned-on by default.
to provide metrics via the resource metrics API, as Horizontal Pod Autoscaler uses this API to collect metrics. The instructions for deploying this are on the GitHub repository of [metrics-server](https://github.com/kubernetes-incubator/metrics-server/), if you followed [getting started on GCE guide](/docs/setup/production-environment/turnkey/gce/),
metrics-server monitoring will be turned-on by default.
To specify multiple resource metrics for a Horizontal Pod Autoscaler, you must have a Kubernetes cluster
and kubectl at version 1.6 or later. Furthermore, in order to make use of custom metrics, your cluster
@@ -75,7 +75,7 @@ deployment.apps/php-apache created
## Create Horizontal Pod Autoscaler
Now that the server is running, we will create the autoscaler using
[kubectl autoscale](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_autoscale.md).
[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale).
The following command will create a Horizontal Pod Autoscaler that maintains between 1 and 10 replicas of the Pods
controlled by the php-apache deployment we created in the first step of these instructions.
Roughly speaking, HPA will increase and decrease the number of replicas
@@ -271,7 +271,7 @@ object:
metric:
name: requests-per-second
describedObject:
apiVersion: extensions/v1beta1
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
name: main-route
target:
@@ -316,7 +316,7 @@ spec:
metric:
name: requests-per-second
describedObject:
apiVersion: extensions/v1beta1
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
name: main-route
target:
@@ -339,7 +339,7 @@ status:
metric:
name: requests-per-second
describedObject:
apiVersion: extensions/v1beta1
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
name: main-route
current:
content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
+3 -3
View File
@@ -71,7 +71,7 @@ or the custom metrics API (for all other metrics).
The HorizontalPodAutoscaler normally fetches metrics from a series of aggregated APIs (`metrics.k8s.io`,
`custom.metrics.k8s.io`, and `external.metrics.k8s.io`). The `metrics.k8s.io` API is usually provided by
metrics-server, which needs to be launched separately. See
[metrics-server](/docs/tasks/debug-application-cluster/core-metrics-pipeline/#metrics-server)
[metrics-server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server)
for instructions. The HorizontalPodAutoscaler can also fetch metrics directly from Heapster.
{{< note >}}
@@ -164,7 +164,7 @@ the current value.
Finally, just before HPA scales the target, the scale recommendation is recorded. 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.
highest recommendation from within that window. This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization` flag, which defaults to 5 minutes.
This means that scaledowns will occur gradually, smoothing out the impact of rapidly
fluctuating metric values.
@@ -219,7 +219,7 @@ the global HPA settings exposed as flags for the `kube-controller-manager` compo
Starting from v1.12, a new algorithmic update removes the need for the
upscale delay.
- `--horizontal-pod-autoscaler-downscale-delay`: The value for this option is a
- `--horizontal-pod-autoscaler-downscale-stabilization`: The value for this option is a
duration that specifies how long the autoscaler has to wait before another
downscale operation can be performed after the current one has completed.
The default value is 5 minutes (`5m0s`).
content/en/docs/tasks/run-application/rolling-update-replication-controller.md
+31 -57
View File
@@ -37,8 +37,12 @@ A rolling update works by:
Rolling updates are initiated with the `kubectl rolling-update` command:
kubectl rolling-update NAME \
([NEW_NAME] --image=IMAGE | -f FILE)
```shell
kubectl rolling-update NAME NEW_NAME --image=IMAGE:TAG
# or read the configuration from a file
kubectl rolling-update NAME -f FILE
```
{{% /capture %}}
@@ -50,7 +54,9 @@ Rolling updates are initiated with the `kubectl rolling-update` command:
To initiate a rolling update using a configuration file, pass the new file to
`kubectl rolling-update`:
kubectl rolling-update NAME -f FILE
```shell
kubectl rolling-update NAME -f FILE
```
The configuration file must:
@@ -65,25 +71,29 @@ Replication controller configuration files are described in
### Examples
// Update pods of frontend-v1 using new replication controller data in frontend-v2.json.
kubectl rolling-update frontend-v1 -f frontend-v2.json
```shell
# Update pods of frontend-v1 using new replication controller data in frontend-v2.json.
kubectl rolling-update frontend-v1 -f frontend-v2.json
// Update pods of frontend-v1 using JSON data passed into stdin.
cat frontend-v2.json | kubectl rolling-update frontend-v1 -f -
# Update pods of frontend-v1 using JSON data passed into stdin.
cat frontend-v2.json | kubectl rolling-update frontend-v1 -f -
```
## Updating the container image
To update only the container image, pass a new image name and tag with the
`--image` flag and (optionally) a new controller name:
kubectl rolling-update NAME [NEW_NAME] --image=IMAGE:TAG
```shell
kubectl rolling-update NAME NEW_NAME --image=IMAGE:TAG
```
The `--image` flag is only supported for single-container pods. Specifying
`--image` with multi-container pods returns an error.
If no `NEW_NAME` is specified, a new replication controller is created with
a temporary name. Once the rollout is complete, the old controller is deleted,
and the new controller is updated to use the original name.
If you didn't specify a new name, this creates a new replication controller
with a temporary name. Once the rollout is complete, the old controller is
deleted, and the new controller is updated to use the original name.
The update will fail if `IMAGE:TAG` is identical to the
current value. For this reason, we recommend the use of versioned tags as
@@ -94,11 +104,13 @@ Moreover, the use of `:latest` is not recommended, see
### Examples
// Update the pods of frontend-v1 to frontend-v2
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2
```shell
# Update the pods of frontend-v1 to frontend-v2
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2
// Update the pods of frontend, keeping the replication controller name
kubectl rolling-update frontend --image=image:v2
# Update the pods of frontend, keeping the replication controller name
kubectl rolling-update frontend --image=image:v2
```
## Required and optional fields
@@ -143,24 +155,7 @@ from the [`kubectl` reference](/docs/reference/generated/kubectl/kubectl-command
Let's say you were running version 1.7.9 of nginx:
```yaml
apiVersion: v1
kind: ReplicationController
metadata:
name: my-nginx
spec:
replicas: 5
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
```
{{< codenew file="controllers/replication-nginx-1.7.9.yaml" >}}
To update to version 1.9.1, you can use [`kubectl rolling-update --image`](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) to specify the new image:
@@ -218,34 +213,13 @@ This is one example where the immutability of containers is a huge asset.
If you need to update more than just the image (e.g., command arguments, environment variables), you can create a new replication controller, with a new name and distinguishing label value, such as:
```yaml
apiVersion: v1
kind: ReplicationController
metadata:
name: my-nginx-v4
spec:
replicas: 5
selector:
app: nginx
deployment: v4
template:
metadata:
labels:
app: nginx
deployment: v4
spec:
containers:
- name: nginx
image: nginx:1.9.2
args: ["nginx", "-T"]
ports:
- containerPort: 80
```
{{< codenew file="controllers/replication-nginx-1.9.2.yaml" >}}
and roll it out:
```shell
kubectl rolling-update my-nginx -f ./nginx-rc.yaml
# Assuming you named the file "my-nginx.yaml"
kubectl rolling-update my-nginx -f ./my-nginx.yaml
```
```
Created my-nginx-v4
content/en/docs/tasks/run-application/run-replicated-stateful-application.md
+8 -8
View File
@@ -59,12 +59,12 @@ and a StatefulSet.
Create the ConfigMap from the following YAML configuration file:
{{< codenew file="application/mysql/mysql-configmap.yaml" >}}
```shell
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml
```
{{< codenew file="application/mysql/mysql-configmap.yaml" >}}
This ConfigMap provides `my.cnf` overrides that let you independently control
configuration on the MySQL master and slaves.
In this case, you want the master to be able to serve replication logs to slaves
@@ -79,12 +79,12 @@ based on information provided by the StatefulSet controller.
Create the Services from the following YAML configuration file:
{{< codenew file="application/mysql/mysql-services.yaml" >}}
```shell
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml
```
{{< codenew file="application/mysql/mysql-services.yaml" >}}
The Headless Service provides a home for the DNS entries that the StatefulSet
controller creates for each Pod that's part of the set.
Because the Headless Service is named `mysql`, the Pods are accessible by
@@ -105,12 +105,12 @@ writes.
Finally, create the StatefulSet from the following YAML configuration file:
{{< codenew file="application/mysql/mysql-statefulset.yaml" >}}
```shell
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-statefulset.yaml
```
{{< codenew file="application/mysql/mysql-statefulset.yaml" >}}
You can watch the startup progress by running:
```shell
@@ -141,8 +141,8 @@ ordinal index.
It waits until each Pod reports being Ready before starting the next one.
In addition, the controller assigns each Pod a unique, stable name of the form
`<statefulset-name>-<ordinal-index>`.
In this case, that results in Pods named `mysql-0`, `mysql-1`, and `mysql-2`.
`<statefulset-name>-<ordinal-index>`, which results in Pods named `mysql-0`,
`mysql-1`, and `mysql-2`.
The Pod template in the above StatefulSet manifest takes advantage of these
properties to perform orderly startup of MySQL replication.
content/en/docs/tasks/run-application/update-api-object-kubectl-patch.md
+4 -6
View File
@@ -330,11 +330,9 @@ and
{{% capture whatsnext %}}
* [Kubernetes Object Management](/docs/concepts/overview/object-management-kubectl/overview/)
* [Managing Kubernetes Objects Using Imperative Commands](/docs/concepts/overview/object-management-kubectl/imperative-command/)
* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/concepts/overview/object-management-kubectl/imperative-config/)
* [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/concepts/overview/object-management-kubectl/declarative-config/)
* [Kubernetes Object Management](/docs/concepts/overview/working-with-objects/object-management/)
* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/)
* [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/declarative-config/)
{{% /capture %}}