Split documentation according to both mechanisms available for migration

Kubernetes-commit: 7f893f6bd62357e52ee77ddc64dd163a4a5f1224
This commit is contained in:
Joe Betz
2021-06-23 10:30:58 -07:00
committed by Kubernetes Publisher
parent acf46abf8c
commit 50ffc02e9b

View File

@@ -14,7 +14,7 @@ See the License for the specific language governing permissions and
limitations under the License.
*/
// Code generated by client-gen. DO NOT EDIT.
// Code generated by applyconfiguration-gen. DO NOT EDIT.
/*
Package applyconfigurations provides typesafe go representations of the apply
@@ -104,7 +104,10 @@ representation to be changed to support additional features in the future.
Controller Support
The new client-go support makes it much easier to use Server-side Apply in controllers, by either of two mechanisms.
The new client-go support makes it much easier to use Server-side Apply in controllers, by either of
two mechanisms.
Mechanism 1:
When authoring new controllers to use Server-side Apply, a good approach is to have the controller
recreate the apply configuration for an object each time it reconciles that object. This ensures
@@ -115,13 +118,17 @@ reconciliation loop that apply is called from.
When upgrading existing controllers to use Server-side Apply the same approach often works
well--migrate the controllers to recreate the apply configuration each time it reconciles any
object. Unfortunately, the controller might have multiple code paths that update different parts of
an object depending on various conditions. Migrating a controller like this to Server-side Apply can
be risky because if the controller forgets to include any fields in an apply configuration that is
included in a previous apply request, a field can be accidentlly deleted. To ease this type of
migration, client-go apply support provides a way to replace any controller reconciliation code that
performs a "read/modify-in-place/update" (or patch) workflow with a "extract/modify-in-place/apply"
workflow. Here's an example of the new workflow:
object. For cases where this does not work well, see Mechanism 2.
Mechanism 2:
When upgrading existing controllers to use Server-side Apply, the controller might have multiple
code paths that update different parts of an object depending on various conditions. Migrating a
controller like this to Server-side Apply can be risky because if the controller forgets to include
any fields in an apply configuration that is included in a previous apply request, a field can be
accidentally deleted. For such cases, an alternative to mechanism 1 is to replace any controller
reconciliation code that performs a "read/modify-in-place/update" (or patch) workflow with a
"extract/modify-in-place/apply" workflow. Here's an example of the new workflow:
fieldMgr := "my-field-manager"
deploymentClient := clientset.AppsV1().Deployments("default")