github/client-go
1
0
Fork 0
mirror of https://github.com/kubernetes/client-go.git synced 2025-09-02 15:45:09 +00:00
Code Issues Projects Releases Wiki Activity

Split documentation according to both mechanisms available for migration

Browse Source 
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
1 changed files with 16 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
applyconfigurations/doc.go
View File

@@ -14,7 +14,7 @@ See the License for the specific language governing permissions and
limitations under the License. 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 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 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 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 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 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 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 object. For cases where this does not work well, see Mechanism 2.
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 Mechanism 2:
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 When upgrading existing controllers to use Server-side Apply, the controller might have multiple
performs a "read/modify-in-place/update" (or patch) workflow with a "extract/modify-in-place/apply" code paths that update different parts of an object depending on various conditions. Migrating a
workflow. Here's an example of the new workflow: 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" fieldMgr := "my-field-manager"
deploymentClient := clientset.AppsV1().Deployments("default") deploymentClient := clientset.AppsV1().Deployments("default")