merge master to 1.10, with fixes (#7682)
This commit is contained in:
Jennifer Rondeau
committed by
k8s-ci-robot
k8s-ci-robot
parent
bb8c59a640
commit
44b51d6056
@@ -1,11 +1,11 @@
|
||||
---
|
||||
approvers:
|
||||
reviewers:
|
||||
- bprashanth
|
||||
- erictune
|
||||
- foxish
|
||||
- janetkuo
|
||||
- smarterclayton
|
||||
title: Delete a Stateful Set
|
||||
title: Delete a StatefulSet
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
@@ -40,7 +40,8 @@ You may need to delete the associated headless service separately after the Stat
|
||||
kubectl delete service <service-name>
|
||||
```
|
||||
|
||||
Deleting a StatefulSet through kubectl will scale it down to 0, thereby deleting all pods that are a part of it. If you want to delete just the StatefulSet and not the pods, use `--cascade=false`.
|
||||
Deleting a StatefulSet through kubectl will scale it down to 0, thereby deleting all pods that are a part of it.
|
||||
If you want to delete just the StatefulSet and not the pods, use `--cascade=false`.
|
||||
|
||||
```shell
|
||||
kubectl delete -f <file.yaml> --cascade=false
|
||||
|
||||
@@ -15,3 +15,7 @@ spec:
|
||||
containers:
|
||||
- name: patch-demo-ctr
|
||||
image: nginx
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: dedicated
|
||||
value: test-team
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
approvers:
|
||||
reviewers:
|
||||
- bprashanth
|
||||
- erictune
|
||||
- foxish
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
approvers:
|
||||
reviewers:
|
||||
- fgrzadkowski
|
||||
- jszczepkowski
|
||||
- justinsb
|
||||
@@ -7,6 +7,9 @@ approvers:
|
||||
title: Horizontal Pod Autoscaler Walkthrough
|
||||
---
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
Horizontal Pod Autoscaler automatically scales the number of pods
|
||||
in a replication controller, deployment or replica set based on observed CPU utilization
|
||||
(or, with beta support, on some other, application-provided metrics).
|
||||
@@ -29,8 +32,25 @@ See the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horiz
|
||||
## Step One: Run & expose php-apache server
|
||||
|
||||
To demonstrate Horizontal Pod Autoscaler we will use a custom docker image based on the php-apache image.
|
||||
The Dockerfile can be found [here](/docs/user-guide/horizontal-pod-autoscaling/image/Dockerfile).
|
||||
It defines an [index.php](/docs/user-guide/horizontal-pod-autoscaling/image/index.php) page which performs some CPU intensive computations.
|
||||
The Dockerfile has the following content:
|
||||
|
||||
```
|
||||
FROM php:5-apache
|
||||
ADD index.php /var/www/html/index.php
|
||||
RUN chmod a+rx index.php
|
||||
```
|
||||
|
||||
It defines an index.php page which performs some CPU intensive computations:
|
||||
|
||||
```
|
||||
<?php
|
||||
$x = 0.0001;
|
||||
for ($i = 0; $i <= 1000000; $i++) {
|
||||
$x += sqrt($x);
|
||||
}
|
||||
echo "OK!";
|
||||
?>
|
||||
```
|
||||
|
||||
First, we will start a deployment running the image and expose it as a service:
|
||||
|
||||
|
||||
@@ -1,11 +1,14 @@
|
||||
---
|
||||
approvers:
|
||||
reviewers:
|
||||
- fgrzadkowski
|
||||
- jszczepkowski
|
||||
- directxman12
|
||||
title: Horizontal Pod Autoscaler
|
||||
---
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
This document describes the current state of the Horizontal Pod Autoscaler in Kubernetes.
|
||||
|
||||
## What is the Horizontal Pod Autoscaler?
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
approvers:
|
||||
reviewers:
|
||||
- janetkuo
|
||||
title: Perform Rolling Update Using a Replication Controller
|
||||
---
|
||||
@@ -15,8 +15,9 @@ which in turn uses a
|
||||
[ReplicaSet](/docs/api-reference/{{page.version}}/#replicaset-v1beta1-extensions).
|
||||
For more information, see
|
||||
[Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
|
||||
{: .note}
|
||||
|
||||
To update a service without an outage, `kubectl` supports what is called [rolling update](/docs/user-guide/kubectl/{{page.version}}/#rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) and the [example of rolling update](/docs/tasks/run-application/rolling-update-replication-controller/) for more information.
|
||||
To update a service without an outage, `kubectl` supports what is called [rolling update](/docs/user-guide/kubectl/{{page.version}}/#rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) for more information.
|
||||
|
||||
Note that `kubectl rolling-update` only supports Replication Controllers. However, if you deploy applications with Replication Controllers,
|
||||
consider switching them to [Deployments](/docs/concepts/workloads/controllers/deployment/). A Deployment is a higher-level controller that automates rolling updates
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
approvers:
|
||||
reviewers:
|
||||
- enisoc
|
||||
- erictune
|
||||
- foxish
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Run a Stateless Application Using a Deployment
|
||||
min-kubernetes-server-version: v1.8
|
||||
min-kubernetes-server-version: v1.9
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
approvers:
|
||||
reviewers:
|
||||
- bprashanth
|
||||
- enisoc
|
||||
- erictune
|
||||
|
||||
@@ -54,9 +54,9 @@ get terminated and replaced by new ones.
|
||||
At this point, each Pod has one Container that runs the nginx image. Now suppose
|
||||
you want each Pod to have two containers: one that runs nginx and one that runs redis.
|
||||
|
||||
Create a file named `patch-file.yaml` that has this content:
|
||||
Create a file named `patch-file-containers.yaml` that has this content:
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
@@ -68,7 +68,7 @@ spec:
|
||||
Patch your Deployment:
|
||||
|
||||
```shell
|
||||
kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)"
|
||||
kubectl patch deployment patch-demo --patch "$(cat patch-file-containers.yaml)"
|
||||
```
|
||||
|
||||
View the patched Deployment:
|
||||
@@ -126,15 +126,82 @@ containers:
|
||||
|
||||
### Notes on the strategic merge patch
|
||||
|
||||
With a patch, you do not have to specify an entire object; you specify only the portion
|
||||
of the object that you want to change. For example, in the preceding exercise, you specified
|
||||
one Container in the `containers` list in a `PodSpec`.
|
||||
|
||||
The patch you did in the preceding exercise is called a *strategic merge patch*.
|
||||
With a strategic merge patch, you can update a list by specifying only the elements
|
||||
that you want to add to the list. The existing list elements remain, and the new elements
|
||||
are merged with the existing elements. In the preceding exercise, the resulting `containers`
|
||||
list has both the original nginx Container and the new redis Container.
|
||||
Notice that the patch did not replace the `containers` list. Instead it added a new
|
||||
Container to the list. In other words, the list in the patch was merged with the
|
||||
existing list. This is not always what happens when you use a strategic merge patch on a list.
|
||||
In some cases, the list is replaced, not merged.
|
||||
|
||||
With a strategic merge patch, a list is either replaced or merged depending on its
|
||||
patch strategy. The patch strategy is specified by the value of the `patchStrategy` key
|
||||
in a field tag in the Kubernetes source code. For example, the `Containers` field of `PodSpec`
|
||||
struct has a `patchStrategy` of `merge`:
|
||||
|
||||
```go
|
||||
type PodSpec struct {
|
||||
...
|
||||
Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name" ...`
|
||||
```
|
||||
|
||||
You can also see the patch strategy in the
|
||||
[OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json):
|
||||
|
||||
```json
|
||||
"io.k8s.api.core.v1.PodSpec": {
|
||||
...
|
||||
"containers": {
|
||||
"description": "List of containers belonging to the pod. ...
|
||||
},
|
||||
"x-kubernetes-patch-merge-key": "name",
|
||||
"x-kubernetes-patch-strategy": "merge"
|
||||
},
|
||||
```
|
||||
|
||||
And you can see the patch strategy in the
|
||||
[Kubernetes API documentation](/docs/reference/generated/kubernetes-api/v1.9/#podspec-v1-core).
|
||||
|
||||
Create a file named `patch-file-tolerations.yaml` that has this content:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: disktype
|
||||
value: ssd
|
||||
```
|
||||
|
||||
Patch your Deployment:
|
||||
|
||||
```shell
|
||||
kubectl patch deployment patch-demo --patch "$(cat patch-file-tolerations.yaml)"
|
||||
```
|
||||
|
||||
View the patched Deployment:
|
||||
|
||||
```shell
|
||||
kubectl get deployment patch-demo --output yaml
|
||||
```
|
||||
|
||||
The output shows that the PodSpec in the Deployment has only one Toleration:
|
||||
|
||||
```shell
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: disktype
|
||||
value: ssd
|
||||
```
|
||||
|
||||
Notice that the `tolerations` list in the PodSpec was replaced, not merged. This is because
|
||||
the Tolerations field of PodSpec does not have a `patchStrategy` key in its field tag. So the
|
||||
strategic merge patch uses the default patch strategy, which is `replace`.
|
||||
|
||||
```go
|
||||
type PodSpec struct {
|
||||
...
|
||||
Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"`
|
||||
```
|
||||
|
||||
## Use a JSON merge patch to update a Deployment
|
||||
|
||||
@@ -162,7 +229,7 @@ did a strategic merge patch.
|
||||
Next, do a JSON merge patch on your same Deployment. Create a file named `patch-file-2.yaml`
|
||||
that has this content:
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
@@ -216,7 +283,7 @@ directly on the command line.
|
||||
|
||||
Create a file named `patch-file.json` that has this content:
|
||||
|
||||
```shell
|
||||
```json
|
||||
{
|
||||
"spec": {
|
||||
"template": {
|
||||
@@ -246,7 +313,7 @@ kubectl patch deployment patch-demo --patch '{"spec": {"template": {"spec": {"co
|
||||
|
||||
## Summary
|
||||
|
||||
In this exercise, you `kubectl patch` to change the live configuration
|
||||
In this exercise, you used `kubectl patch` to change the live configuration
|
||||
of a Deployment object. You did not change the configuration file that you originally used to
|
||||
create the Deployment object. Other commands for updating API objects include
|
||||
[kubectl annotate](/docs/user-guide/kubectl/{{page.version}}/#annotate),
|
||||
|
||||
Reference in New Issue
Block a user