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-16 09:30:37 -07:00
parent db171119ac 98e2c105ef
commit 1798434784
19 changed files with 59 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/abstractions/pod-termination.md
+3 -2
View File
@@ -8,8 +8,9 @@ Since Pods represent processes running on your cluster, Kubernetes provides for
1. You send a command or API call to terminate the Pod.
1. Kubernetes updates the Pod status to reflect the time after which the Pod is to be considered "dead" (the time of the termination request plus the grace period).
1. Kubernetes marks the Pod state as "Terminating" and stops sending traffic to the Pod.
1. Kubernetes send a `TERM` signal to the Pod, indicating that the Pod should shut down.
1. Kubernetes sends a `TERM` signal to the Pod, indicating that the Pod should shut down.
1. When the grace period expires, Kubernetes issues a `SIGKILL` to any processes still running in the Pod.
1. Kubernetes removes the Pod from the API server on the Kubernetes Master.
> **Note:** The grace period is configurable; you can set your own grace period when interacting with the cluster to request termination, such as using the `kubectl delete` command. See the [Terminating a Pod]() tutorial for more information.
> **Note:** The grace period is configurable; you can set your own grace period when interacting with the cluster to request termination, such as using the `kubectl delete` command. See the [Terminating a Pod]() tutorial for more information.
{: .note}
docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
+1 -1
View File
@@ -38,7 +38,7 @@ by default, the hosts file only includes ipv4 and ipv6 boilerplates like `localh
## Adding Additional Entries with HostAliases
In addition the the default boilerplate, we can add additional entries to the hosts file to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`, `bar.remote` to `10.1.2.3`, we can by adding HostAliases to the Pod under `.spec.hostAliases`:
In addition to the default boilerplate, we can add additional entries to the hosts file to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`, `bar.remote` to `10.1.2.3`, we can by adding HostAliases to the Pod under `.spec.hostAliases`:
{% include code.html language="yaml" file="hostaliases-pod.yaml" ghlink="/docs/concepts/services-networking/hostaliases-pod.yaml" %}