Repository navigation
Change status.conditions to the Kubernetes format #552
Description
The current conditions field looks like the following:
type ResourceCondition struct {
Condition ResourceConditionType `json:"condition,omitempty"`
Status metav1.ConditionStatus `json:"status,omitempty"`
Action ReconcileAction `json:"action,omitempty"`
}If we use Kubernetes-format Conditions, we can carry some textual information through the message and reason fields that can help improve the usability of Function Mesh
Activity
tpiperatgod commentedon Jan 12, 2023
Overview
The current Operator reconciliation workflow is to observe the maintained resource and update its status first, and then determine whether to reconcile the resource based on the status, and update its status after reconciliation.
We can see that the ability to effectively and accurately compare the state of resources in the cluster with the desired resource state is key to determining whether we need to make reconciliation or not.
This requires us to provide a reasonable set of judgment criteria which should be
On the other hand, we can use Kubernetes' native Condition as the CRD.Status.Conditions format. The benefits are as follows.
reason,message,observedGeneration, etc. to enrich the information in CRDProposal
The proposal is as follows.
Changing the style of CRD.Status
The current CRD.Status style is as follows.
Where the
Conditionsfield will be changed frommap[Component]ResourceConditionto[]metav1.Condition.Because the
ObservedGenerationfield is already present in Condition, we can remove theCRD.Status.ObservedGenerationThe expected style is as follows.
For a sub-component, the followings are added.
StatefulSetReadyErrorCreating<Component>, which means the resource creation failed<Component>Error, indicating an exception during the observe phase<Component>IsReady, which means the resource is readyGeneric Condition content.
Ready, means the CRD is readywill be determined based on the condition type of the sub-components
Error, means the CRD is abnormal or not readyPendingCreation, means the resource is pending to be createdAnd in
ComponentsGenerationsthe latest ObservedGeneration of sub-component is stored.ObservedGenerationsof sub-components are recorded in CRD.Status, and the ObservedGeneration is compared with the actual value of generation of sub-component in the cluster to determine whether the resource needs to be updated, according to the following rules.After reconciling a sub-component, update the actual value of generation of the sub—component in the cluster as the ObservedGeneration
Case
The following assumes that the current CRD maintains one sub-component (StatefulSet) and demonstrates the full Operator process.