mirror of
https://github.com/kubernetes/client-go.git
synced 2025-09-01 23:31:51 +00:00
Split documentation according to both mechanisms available for migration
Kubernetes-commit: 7f893f6bd62357e52ee77ddc64dd163a4a5f1224
This commit is contained in:
committed by
Kubernetes Publisher
parent
acf46abf8c
commit
50ffc02e9b
@@ -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")
|
||||
|
Reference in New Issue
Block a user