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

Changes for move to Netlify (#4464)

Browse Source 
* disable jekyll-redirect-from gem

* add _redirects file

* disable 404 redirect script

* add 301 redirect to test

* retain _redirects file

* Convert redirect_from's to _redirect file. (#4409)

* Remove redirect_from's. (#4424)

* Add 301's to _redirects. (#4427)

* add whitespace before 301

* move redirects in /js/redirects/js to _redirects

* add disabled option for cn redirect

* convert include to array in _config.yml

* enable redirects.js script for legacy support
This commit is contained in:
Andrew Chen
2017-07-28 08:23:11 -07:00
committed by GitHub
parent 130b72927c
commit 2e257d9707
158 changed files with 624 additions and 1011 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/workloads/controllers/garbage-collection.md
+6 -12
View File
@@ -1,11 +1,5 @@
---
title: Garbage Collection
redirect_from:
- "/docs/concepts/abstractions/controllers/garbage-collection/"
- "/docs/concepts/abstractions/controllers/garbage-collection.html"
- "/docs/user-guide/garbage-collection/"
- "/docs/user-guide/garbage-collection.html"
---
{% capture overview %}
@@ -70,15 +64,15 @@ metadata:
When you delete an object, you can specify whether the object's dependents are
also deleted automatically. Deleting dependents automatically is called *cascading
deletion*. There are two modes of *cascading deletion*: *background* and *foreground*.
deletion*. There are two modes of *cascading deletion*: *background* and *foreground*.
If you delete an object without deleting its dependents
automatically, the dependents are said to be *orphaned*.
automatically, the dependents are said to be *orphaned*.
### Background cascading deletion
In *background cascading deletion*, Kubernetes deletes the owner object
immediately and the garbage collector then deletes the dependents in
In *background cascading deletion*, Kubernetes deletes the owner object
immediately and the garbage collector then deletes the dependents in
the background.
### Foreground cascading deletion
@@ -90,7 +84,7 @@ the following things are true:
* The object is still visible via the REST API
* The object's `deletionTimestamp` is set
* The object's `metadata.finalizers` contains the value "foregroundDeletion".
Once the "deletion in progress" state is set, the garbage
collector deletes the object's dependents. Once the garbage collector has deleted all
"blocking" dependents (objects with `ownerReference.blockOwnerDeletion=true`), it delete
@@ -100,7 +94,7 @@ Note that in the "foregroundDeletion", only dependents with
`ownerReference.blockOwnerDeletion` block the deletion of the owner object.
Kubernetes version 1.7 will add an admission controller that controls user access to set
`blockOwnerDeletion` to true based on delete permissions on the owner object, so that
unauthorized dependents cannot delay deletion of an owner object.
unauthorized dependents cannot delay deletion of an owner object.
If an object's `ownerReferences` field is set by a controller (such as Deployment or ReplicaSet),
blockOwnerDeletion is set automatically and you do not need to manually modify this field.