Скачать или смотреть azure K8s controller update status and condition Stack Overflow Google Chrome 2023 06 11 05 23

Link:
https://stackoverflow.com/questions/7...


This is the first time that I use status and conditions, is it right way or do I miss something?

Your approach to managing the status and conditions of Kubernetes resources is generally fine. The status subresource in a Kubernetes API object is typically used to represent the current state of the system, and it can include conditions.

A condition is a collection of fields that describe the state of an object in a more detailed way than just true or false. Each condition typically has a type, status, reason, message, and lastTransitionTime. Your code correctly sets these fields based on whether the vfm custom resource is ready or not.

Link

It is good to note that conditions should be leveled - meaning they should be set to their current observed value regardless of their previous value. They should also be set (either true, false, or unknown) for all the significant or user-meaningful aspects of the component's current state. This makes conditions a good mechanism to indicate "transient states" like Progressing or Degraded that might be expected to change over time or based on external state.

Sometimes when I do the update r.Status().Update I got error: Operation cannot be fulfilled on eds.core.vtw.bmw.com “resource01”: the object has been modified; please apply your changes to the latest version and try again.

This error occurs because another client updated the same object while your controller was processing it. This could be another controller or even another instance of the same controller (if you run more than one).

One possible way to handle this is to use a retry mechanism that re-attempts the status update when this error occurs. In your case, you have implemented a conditionChanged check to only attempt the status update if the condition has changed. This is a good approach to avoid unnecessary updates, but it does not completely prevent the error, because another client could still update the object between your Get call and Status().Update call.

You could also consider using Patch instead of Update to modify the status, which reduces the risk of conflicting with other updates. Patching allows for partial updates to an object, so you are less likely to encounter conflicts.

Regarding the timing issue, you could consider updating the LastTransitionTime only when the status actually changes, instead of every time the health check is done. This would mean the LastTransitionTime reflects when the status last changed, rather than the last time the check was performed.

One thing to keep in mind is that frequent updates to the status subresource, even if the status does not change, can cause unnecessary API server load. You should strive to update the status only when it changes.