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

Merge branch 'master' into release-1.8

Browse Source
This commit is contained in:
steveperry-53
2017-08-14 13:09:40 -07:00
parent b6ed75c95d 77086a90b8
commit db171119ac
54 changed files with 1021 additions and 134 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/tasks/access-application-cluster/access-cluster.md
+1 -1
View File
@@ -147,7 +147,7 @@ See documentation for other libraries for how they authenticate.
### Accessing the API from a Pod
When accessing the API from a pod, locating and authenticating
to the api server are somewhat different.
to the apiserver are somewhat different.
The recommended way to locate the apiserver within the pod is with
the `kubernetes` DNS name, which resolves to a Service IP which in turn
docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
+2 -2
View File
@@ -64,11 +64,11 @@ for database debugging.
1. Start the Redis command line interface:
redis-cli
redis-cli
1. At the Redis command line prompt, enter the `ping` command:
127.0.0.1:6379>ping
127.0.0.1:6379>ping
A successful ping request returns PONG.
docs/tasks/configure-pod-container/assign-cpu-resource.md
+3 -3
View File
@@ -16,7 +16,7 @@ but is not allowed to use more CPU than its limit.
{% include task-tutorial-prereqs.md %}
Each node in your cluster must have at least 1 CPU.
Each node in your cluster must have at least 1 cpu.
A few of the steps on this page require that the
[Heapster](https://github.com/kubernetes/heapster) service is running
@@ -55,7 +55,7 @@ kubectl create namespace cpu-example
To specify a CPU request for a Container, include the `resources:requests` field
in the Container's resource manifest. To specify a CPU limit, include `resources:limits`.
In this exercise, you create a Pod that has one Container. The container has a CPU
In this exercise, you create a Pod that has one Container. The Container has a CPU
request of 0.5 cpu and a CPU limit of 1 cpu. Here's the configuration file
for the Pod:
@@ -116,7 +116,7 @@ the limit of 1 cpu specified in the Pod's configuration file.
```
Recall that by setting `-cpu "2"`, you configured the Container to attempt to use 2 cpus.
But the container is only being allowed to use about 1 cpu. The Container's CPU use is being
But the Container is only being allowed to use about 1 cpu. The Container's CPU use is being
throttled, because the Container is attempting to use more CPU resources than its limit.
Note: There's another possible explanation for the CPU throttling. The Node might not have
docs/tasks/configure-pod-container/assign-memory-resource.md
+5 -5
View File
@@ -54,7 +54,7 @@ kubectl create namespace mem-example
To specify a memory request for a Container, include the `resources:requests` field
in the Container's resource manifest. To specify a memory limit, include `resources:limits`.
In this exercise, you create a Pod that has one Container. The container has a memory
In this exercise, you create a Pod that has one Container. The Container has a memory
request of 100 MiB and a memory limit of 200 MiB. Here's the configuration file
for the Pod:
@@ -127,7 +127,7 @@ kubectl delete pod memory-demo --namespace=mem-example
## Exceed a Container's memory limit
A Container can exceed its memory request if the Node has memory available. But a Container
is not allowed to use more than its memory limit. If a container allocates more memory than
is not allowed to use more than its memory limit. If a Container allocates more memory than
its limit, the Container becomes a candidate for termination. If the Container continues to
to consume memory beyond its limit, the Container is terminated. If a terminated Container is
restartable, the kubelet will restart it, as with any other type of runtime failure.
@@ -341,15 +341,15 @@ kubectl delete namespace mem-example
### For app developers
* [Assign CPU Resources to Containers and Pods](docs/tasks/configure-pod-container/assign-cpu-resource/)
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
### For cluster administrators
* [Configure Default Memory Requests and Limits for a Namespace](docs/tasks/administer-cluster/default-memory-request-limit/)
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
* [Configure Default CPU Requests and Limits for a Namespace](docs/tasks/administer-cluster/default-cpu-request-limit/)
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
docs/tasks/configure-pod-container/configure-pod-configmap.md
+1 -1
View File
@@ -285,7 +285,7 @@ When a ConfigMap already being consumed in a volume is updated, projected keys a
### Restrictions
1. You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as "optional"). If you reference a ConfigMaps that doesn't exist, the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting.
1. You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as "optional"). If you reference a ConfigMap that doesn't exist, the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting.
1. If you use `envFrom` to define environment variables from ConfigMaps, keys that are considered invalid will be skipped. The pod will be allowed to start, but the invalid names will be recorded in the event log (`InvalidVariableNames`). The log message lists each skipped key. For example:
docs/tasks/configure-pod-container/quality-service-pod.md
+3 -3
View File
@@ -240,13 +240,13 @@ kubectl delete namespace qos-example
* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [Assign CPU Resources to Containers and Pods](docs/tasks/configure-pod-container/assign-cpu-resource/)
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
### For cluster administrators
* [Configure Default Memory Requests and Limits for a Namespace](docs/tasks/administer-cluster/default-memory-request-limit/)
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-memory-request-limit/)
* [Configure Default CPU Requests and Limits for a Namespace](docs/tasks/administer-cluster/default-cpu-request-limit/)
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
docs/tasks/federation/set-up-coredns-provider-federation.md
+1 -1
View File
@@ -98,7 +98,7 @@ coredns-provider.conf has below format:
- `etcd-endpoints` is the endpoint to access etcd.
- `zones` is the federation domain for which CoreDNS is authoritative and is same as --dns-zone-name flag of `kubefed init`.
- `coredns-endpoints` is the endpoint to access coredns server. This is an optional parameter introduced from v1.7 onwards.
- `coredns-endpoints` is the endpoint to access CoreDNS server. This is an optional parameter introduced from v1.7 onwards.
*Note: middleware.etcd.zones in CoreDNS configuration and --dns-zone-name
flag to kubefed init should match.*
docs/tasks/run-application/deployment-patch-demo.yaml
+14
View File
@@ -0,0 +1,14 @@
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: patch-demo
spec:
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: patch-demo-ctr
image: nginx
docs/tasks/run-application/patch-file.json
+14
View File
@@ -0,0 +1,14 @@
{
"spec": {
"template": {
"spec": {
"containers": [
{
"name": "patch-demo-ctr-2",
"image": "redis"
}
]
}
}
}
}
docs/tasks/run-application/update-api-object-kubectl-patch.md
+271
View File
@@ -0,0 +1,271 @@
---
title: Update API Objects in Place Using kubectl patch
description: Use kubectl patch to update Kubernetes API objects in place. Do a strategic merge patch or a JSON merge patch.
---
{% capture overview %}
This task shows how to use `kubectl patch` to update an API object in place. The exercises
in this task demonstrate a strategic merge patch and a JSON merge patch.
{% endcapture %}
{% capture prerequisites %}
{% include task-tutorial-prereqs.md %}
{% endcapture %}
{% capture steps %}
## Use a strategic merge patch to update a Deployment
Here's the configuration file for a Deployment that has two replicas. Each replica
is a Pod that has one container:
{% include code.html language="yaml" file="deployment-patch-demo.yaml" ghlink="/docs/tasks/run-application/deployment-patch-demo.yaml" %}
Create the Deployment:
```shell
kubectl create -f https://k8s.io/docs/tasks/run-application/deployment-patch-demo.yaml
```
View the Pods associated with your Deployment:
```shell
kubectl get pods
```
The output shows that the Deployment has two Pods. The `1/1` indicates that
each Pod has one container:
```
NAME READY STATUS RESTARTS AGE
patch-demo-28633765-670qr 1/1 Running 0 23s
patch-demo-28633765-j5qs3 1/1 Running 0 23s
```
Make a note of the names of the running Pods. Later, you will see that these Pods
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:
```shell
spec:
template:
spec:
containers:
- name: patch-demo-ctr-2
image: redis
```
Patch your Deployment:
```shell
kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)"
```
View the patched Deployment:
```shell
kubectl get deployment patch-demo --output yaml
```
The output shows that the PodSpec in the Deployment has two Containers:
```shell
containers:
- image: nginx
imagePullPolicy: Always
name: patch-demo-ctr
...
- image: redis
imagePullPolicy: Always
name: patch-demo-ctr-2
...
```
View the Pods associated with your patched Deployment:
```shell
kubectl get pods
```
The output shows that the running Pods have different names from the Pods that
were running previously. The Deployment terminated the old Pods and created two
new Pods that comply with the updated Deployment spec. The `2/2` indicates that
each Pod has two Containers:
```
NAME READY STATUS RESTARTS AGE
patch-demo-1081991389-2wrn5 2/2 Running 0 1m
patch-demo-1081991389-jmg7b 2/2 Running 0 1m
```
Take a closer look at one of the patch-demo Pods:
```shell
kubectl get pod <your-pod-name> --output yaml
```
The output shows that the Pod has two Containers: one running nginx and one running redis:
```
containers:
- image: nginx
...
- image: redis
...
```
### 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.
## Use a JSON merge patch to update a Deployment
A strategic merge patch is different from a
[JSON merge patch](https://tools.ietf.org/html/rfc6902).
With a JSON merge patch, if you
want to update a list, you have to specify the entire new list. And the new list completely
replaces the existing list.
The `kubectl patch` command has a `type` parameter that you can set to one of these values:
<table>
<tr><th>Parameter value</th><th>Merge type</th></tr>
<tr><td>json</td><td><a href="https://tools.ietf.org/html/rfc6902">JSON Patch, RFC 6902</a></td></tr>
<tr><td>merge</td><td><a href="https://tools.ietf.org/html/rfc7386">JSON Merge Patch, RFC 7386</a></td></tr>
<tr><td>strategic</td><td>Strategic merge patch</td></tr>
</table>
For a comparison of JSON patch and JSON merge patch, see
[JSON Patch and JSON Merge Patch](http://erosb.github.io/post/json-patch-vs-merge-patch/).
The default value for the `type` parameter is `strategic`. So in the preceding exercise, you
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
spec:
template:
spec:
containers:
- name: patch-demo-ctr-3
image: gcr.io/google-samples/node-hello:1.0
```
In your patch command, set `type` to `merge`:
```shell
kubectl patch deployment patch-demo --type merge --patch "$(cat patch-file-2.yaml)"
```
View the patched Deployment:
```shell
kubectl get deployment patch-demo --output yaml
```
The `containers` list that you specified in the patch has only one Container.
The output shows that your list of one Container replaced the existing `containers` list.
```shell
spec:
containers:
- image: gcr.io/google-samples/node-hello:1.0
...
name: patch-demo-ctr-3
```
List the running Pods:
```shell
kubectl get pods
```
In the output, you can see that the existing Pods were terminated, and new Pods
were created. The `1/1` indicates that each new Pod is running only one Container.
```shell
NAME READY STATUS RESTARTS AGE
patch-demo-1307768864-69308 1/1 Running 0 1m
patch-demo-1307768864-c86dc 1/1 Running 0 1m
```
## Alternate forms of the kubectl patch command
The `kubectl patch` command takes YAML or JSON. It can take the patch as a file or
directly on the command line.
Create a file named `patch-file.json` that has this content:
```shell
{
"spec": {
"template": {
"spec": {
"containers": [
{
"name": "patch-demo-ctr-2",
"image": "redis"
}
]
}
}
}
}
```
The following commands are equivalent:
```shell
kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)"
kubectl patch deployment patch-demo --patch $'spec:\n template:\n spec:\n containers:\n - name: patch-demo-ctr-2\n image: redis'
kubectl patch deployment patch-demo --patch "$(cat patch-file.json)"
kubectl patch deployment patch-demo --patch '{"spec": {"template": {"spec": {"containers": [{"name": "patch-demo-ctr-2","image": "redis"}]}}}}'
```
## Summary
In this exercise, you `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),
[kubectl edit](/docs/user-guide/kubectl/v1.7/#edit),
[kubectl replace](/docs/user-guide/kubectl/v1.7/#replace),
[kubectl scale](/docs/user-guide/kubectl/v1.7/#scale),
[kubectl update](/docs/user-guide/kubectl/v1.7/#update). and
[kubectl apply](/docs/user-guide/kubectl/v1.7/#apply).
{% endcapture %}
{% capture whatsnext %}
* [Kubernetes Object Management](/docs/tutorials/object-management-kubectl/object-management/)
* [Managing Kubernetes Objects Using Imperative Commands](/docs/tutorials/object-management-kubectl/imperative-object-management-command/)
* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tutorials/object-management-kubectl/imperative-object-management-configuration/)
* [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/tutorials/object-management-kubectl/declarative-object-management-configuration/)
{% endcapture %}
{% include templates/task.md %}
docs/tasks/tools/install-kubectl.md
+2 -2
View File
@@ -119,7 +119,7 @@ kubectl is available as a [snap](https://snapcraft.io/) application.
choco install kubernetes-cli
2. Run `kubectl version` to verify that the verison you've installed is sufficiently up-to-date.
3. Configure kubectl to use a remote kubernetes cluster:
3. Configure kubectl to use a remote Kubernetes cluster:
cd C:\users\yourusername (Or wherever your %HOME% directory is)
mkdir .kube
@@ -185,7 +185,7 @@ If you have installed kubectl manually, you need to add kubectl autocompletion t
kubectl completion bash > $(brew --prefix)/etc/bash_completion.d/kubectl
```
The Homebrew project is independent from kubernetes, so the bash-completion packages are not guaranteed to work.
The Homebrew project is independent from Kubernetes, so the bash-completion packages are not guaranteed to work.
### Using Oh-My-Zsh
When using [Oh-My-Zsh](http://ohmyz.sh/), edit the ~/.zshrc file and update the `plugins=` line to include the kubectl plugin.