chore: a new serviceaccount naming policy (#10029)

(cherry picked from commit b893218)

Author: cjc7373

apis/apps/v1/cluster_types.go

@@ -434,11 +434,14 @@ type ClusterComponentSpec struct {
 	// with other Kubernetes resources, such as modifying Pod labels or sending events.
 	//
 	// If not specified, KubeBlocks automatically creates a default ServiceAccount named
-	// "kb-{componentdefinition.name}", bound to a role with rules defined in ComponentDefinition's
+	// "kb-{clusterName}-{compName}", bound to a cluster role with rules defined in ComponentDefinition's
 	// `policyRules` field. If needed (currently this means if any lifecycleAction is enabled),
-	// it will also be bound to a default role named
+	// it will also be bound to a default cluster role named
 	// "kubeblocks-cluster-pod-role", which is installed together with KubeBlocks.
-	// If multiple components use the same ComponentDefinition, they will share one ServiceAccount.
+	//
+	// Before KubeBlocks 1.1, the automatically created serviceaccount is named "kb-{componentdefinition.name}".
+	// To reduce unintended pod restart, old pods still use old serviceaccount. New serviceaccount will be used
+	// when a workload has been restarted.
 	//
 	// If the field is not empty, the specified ServiceAccount will be used, and KubeBlocks will not
 	// create a ServiceAccount. But KubeBlocks does create RoleBindings for the specified ServiceAccount.

apis/apps/v1/component_types.go

@@ -197,11 +197,14 @@ type ComponentSpec struct {
 	// with other Kubernetes resources, such as modifying Pod labels or sending events.
 	//
 	// If not specified, KubeBlocks automatically creates a default ServiceAccount named
-	// "kb-{componentdefinition.name}", bound to a role with rules defined in ComponentDefinition's
+	// "kb-{clusterName}-{compName}", bound to a cluster role with rules defined in ComponentDefinition's
 	// `policyRules` field. If needed (currently this means if any lifecycleAction is enabled),
-	// it will also be bound to a default role named
+	// it will also be bound to a default cluster role named
 	// "kubeblocks-cluster-pod-role", which is installed together with KubeBlocks.
-	// If multiple components use the same ComponentDefinition, they will share one ServiceAccount.
+	//
+	// Before KubeBlocks 1.1, the automatically created serviceaccount is named "kb-{componentdefinition.name}".
+	// To reduce unintended pod restart, old pods still use old serviceaccount. New serviceaccount will be used
+	// when a workload has been restarted.
 	//
 	// If the field is not empty, the specified ServiceAccount will be used, and KubeBlocks will not
 	// create a ServiceAccount. But KubeBlocks does create RoleBindings for the specified ServiceAccount.

apis/workloads/v1/instanceset_types.go

@@ -352,6 +352,13 @@ type InstanceSetStatus struct {
 	// +optional
 	UpdateRevisions map[string]string `json:"updateRevisions,omitempty"`
 
+	// revisions of desired pod template. But the update process is deferred until another pod update process is triggered.
+	// i.e. a running pod may still use a revision in `updateRevisions`.
+	// key is the pod name, value is the revision.
+	//
+	// +optional
+	DeferredUpdatedRevisions map[string]string `json:"deferredUpdatedRevisions,omitempty"`
+
 	// TemplatesStatus represents status of each instance generated by InstanceTemplates.
 	//
 	// +optional

apis/workloads/v1/zz_generated.deepcopy.go

@@ -4156,11 +4156,15 @@ spec:
 
 
                         If not specified, KubeBlocks automatically creates a default ServiceAccount named
-                        "kb-{componentdefinition.name}", bound to a role with rules defined in ComponentDefinition's
+                        "kb-{clusterName}-{compName}", bound to a cluster role with rules defined in ComponentDefinition's
                         `policyRules` field. If needed (currently this means if any lifecycleAction is enabled),
-                        it will also be bound to a default role named
+                        it will also be bound to a default cluster role named
                         "kubeblocks-cluster-pod-role", which is installed together with KubeBlocks.
-                        If multiple components use the same ComponentDefinition, they will share one ServiceAccount.
+
+
+                        Before KubeBlocks 1.1, the automatically created serviceaccount is named "kb-{componentdefinition.name}".
+                        To reduce unintended pod restart, old pods still use old serviceaccount. New serviceaccount will be used
+                        when a workload has been restarted.
 
 
                         If the field is not empty, the specified ServiceAccount will be used, and KubeBlocks will not
@@ -15527,11 +15531,15 @@ spec:
 
 
                             If not specified, KubeBlocks automatically creates a default ServiceAccount named
-                            "kb-{componentdefinition.name}", bound to a role with rules defined in ComponentDefinition's
+                            "kb-{clusterName}-{compName}", bound to a cluster role with rules defined in ComponentDefinition's
                             `policyRules` field. If needed (currently this means if any lifecycleAction is enabled),
-                            it will also be bound to a default role named
+                            it will also be bound to a default cluster role named
                             "kubeblocks-cluster-pod-role", which is installed together with KubeBlocks.
-                            If multiple components use the same ComponentDefinition, they will share one ServiceAccount.
+
+
+                            Before KubeBlocks 1.1, the automatically created serviceaccount is named "kb-{componentdefinition.name}".
+                            To reduce unintended pod restart, old pods still use old serviceaccount. New serviceaccount will be used
+                            when a workload has been restarted.
 
 
                             If the field is not empty, the specified ServiceAccount will be used, and KubeBlocks will not

config/crd/bases/apps.kubeblocks.io_clusters.yaml

@@ -4382,11 +4382,15 @@ spec:
 
 
                   If not specified, KubeBlocks automatically creates a default ServiceAccount named
-                  "kb-{componentdefinition.name}", bound to a role with rules defined in ComponentDefinition's
+                  "kb-{clusterName}-{compName}", bound to a cluster role with rules defined in ComponentDefinition's
                   `policyRules` field. If needed (currently this means if any lifecycleAction is enabled),
-                  it will also be bound to a default role named
+                  it will also be bound to a default cluster role named
                   "kubeblocks-cluster-pod-role", which is installed together with KubeBlocks.
-                  If multiple components use the same ComponentDefinition, they will share one ServiceAccount.
+
+
+                  Before KubeBlocks 1.1, the automatically created serviceaccount is named "kb-{componentdefinition.name}".
+                  To reduce unintended pod restart, old pods still use old serviceaccount. New serviceaccount will be used
+                  when a workload has been restarted.
 
 
                   If the field is not empty, the specified ServiceAccount will be used, and KubeBlocks will not

config/crd/bases/apps.kubeblocks.io_components.yaml

@@ -11743,6 +11743,14 @@ spec:
                   currentRevisions, if not empty, indicates the old version of the InstanceSet used to generate the underlying workload.
                   key is the pod name, value is the revision.
                 type: object
+              deferredUpdatedRevisions:
+                additionalProperties:
+                  type: string
+                description: |-
+                  revisions of desired pod template. But the update process is deferred until another pod update process is triggered.
+                  i.e. a running pod may still use a revision in `updateRevisions`.
+                  key is the pod name, value is the revision.
+                type: object
               initReplicas:
                 description: |-
                   Defines the initial number of instances when the cluster is first initialized.