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

Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.6

Browse Source 
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
  Update hello-minikube.md
  show kubectl_rollingupdate svg
  Fixed flag for eviction-soft.
  Update review-issues.md
  Move Guide topic: Garbage Collection. (#2488)
  Update source-ip.md
  Update source-ip.md
This commit is contained in:
Andrew Chen
2017-02-22 17:18:14 -08:00
parent de68989df2 9dc31d6302
commit 64267ef509
9 changed files with 140 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/user-guide/garbage-collection.md
+2 -31
View File
@@ -4,35 +4,6 @@ assignees:
title: Garbage Collection (Beta)
---
* TOC
{:toc}
{% include user-guide-content-moved.md %}
## Garbage Collection
Note: the Garbage Collection is a beta feature and is enabled by default in Kubernetes version 1.4.
### What does Garbage Collector do
When you delete, for example, a ReplicaSet, it is often desirable for the server to automatically garbage collect all the Pods that the ReplicaSet creates. The Garbage Collector (GC) implements this. In general, when you delete an owner object, GC deletes that owner's dependent objects.
### How to establish an owner-dependent relationship between objects
Kubernetes 1.3 added a metadata.ownerReferences field to every Kubernetes API object. If an API object is a dependent of another object, ownerReference should point to the owning API object.
When you create a ReplicationController or a ReplicaSet in Kubernetes 1.4, the Kubernetes control plane automatically sets the ownerReference field in each created pod to point to the owning ReplicationController or ReplicaSet.
You can set up owner-dependent relationships among other objects by manually setting the ownerReference field on dependent objects.
### Controlling whether Garbage Collector deletes dependents
When deleting an object, you can request the GC to ***asynchronously*** delete its dependents by ***explicitly*** specifying `deleteOptions.orphanDependents=false` in the deletion request that you send to the API server. A 200 OK response from the API server indicates the owner is deleted.
In Kubernetes version 1.5, synchronous garbage collection is under active development. See the tracking [issue](https://github.com/kubernetes/kubernetes/issues/29891) for more details.
If you specify `deleteOptions.orphanDependents=true`, or leave it blank, then the GC will first reset the `ownerReferences` in the dependents, then delete the owner. Note that the deletion of the owner object is asynchronous, that is, a 200 OK response will be sent by the API server before the owner object gets deleted.
### Other references
[Design Doc](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/garbage-collection.md)
[Known issues](https://github.com/kubernetes/kubernetes/issues/26120)
[Garbage Collection](/docs/concepts/abstractions/controllers/garbage-collection/)
docs/user-guide/kubectl/kubectl_rolling-update.md
+1 -1
View File
@@ -13,7 +13,7 @@ Perform a rolling update of the given ReplicationController.
Replaces the specified replication controller with a new replication controller by updating one pod at a time to use the new PodTemplate. The new-controller.json must specify the same namespace as the existing replication controller and overwrite at least one (common) label in its replicaSelector.
! http://kubernetes.io/images/docs/kubectl_rollingupdate.svg
![kubectl_rollingupdate](http://kubernetes.io/images/docs/kubectl_rollingupdate.svg)
```
kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC)