rename operating kuperator (#547)

* rename operating kuperator

* rename operating kuperator1

* rename operating kuperator2

* image url

* operating -> kuperator

* operating -> kuperator

README.md

@@ -49,7 +49,7 @@ Example:
 
 ```bash
 npm run docusaurus docs:version:docs v0.12
-npm run docusaurus docs:version:operating v0.2
+npm run docusaurus docs:version:kuperator v0.2
 npm run docusaurus docs:version:ctrlmesh v0.3
 npm run docusaurus docs:version:karpor v0.4
 
@@ -61,7 +61,7 @@ npm run write-translations -- --locale zh --override
 Optional sub product names:
 
 -   `docs` (alias for kusion)
--   `operating`
+-   `kuperator`
 -   `ctrlmesh`
 -   `karpor`
 

docs/operating/concepts/podopslifecycle.md → docs/kuperator/concepts/podopslifecycle.md

@@ -17,31 +17,31 @@ For instance, removing the Pod's IP from the traffic route before initiating the
 ## Introduction
 
 In PodOpsLifecycle, participants are classified into two roles: `operation controllers` and `cooperation controllers`.
-- **Operation controllers** are responsible for operating Pods, such as Deployments and StatefulSets from Kubernetes, and CollaSets from Operating which intend to scale, update, or recreate Pods.
+- **Operation controllers** are responsible for operating Pods, such as Deployments and StatefulSets from Kubernetes, and CollaSets from Kuperator which intend to scale, update, or recreate Pods.
 - **Cooperation controllers** are sensitive with Pod status. They handle resources or configurations around Pods, which may include traffic controller, alert monitoring controller, etc. These controllers typically reconcile Kubernetes resources around Pods with external services, such as sync Pod IPs with the LB provider, or maintaining Pods' metadata with application monitoring system.
 
-The two types of controllers do not need to be aware of each other. All controllers are organized by PodOpsLifecycle. Additionally, KusionStack Operating introduces extra phases around the native Kubernetes Pod Lifecycle: ServiceAvailable, Preparing, and Completing.
+The two types of controllers do not need to be aware of each other. All controllers are organized by PodOpsLifecycle. Additionally, KusionStack Kuperator introduces extra phases around the native Kubernetes Pod Lifecycle: ServiceAvailable, Preparing, and Completing.
 
-![pod-ops-lifecycle](/img/operating/concepts/podopslifecycle/pod-ops-lifecycle.png)
+![pod-ops-lifecycle](/img/kuperator/concepts/podopslifecycle/pod-ops-lifecycle.png)
 
-- **Completing**: After a Pod is created or updated and becomes ready, Operating marks its PodOpsLifecycle as the `Completing` phase. During this phase, the Pod is in a ready condition, prompting cooperation controllers to perform actions such as registering the Pod IP in the traffic route. Once all cooperation controllers complete their tasks, Operating sets the PodOpsLifecycle to the `ServiceAvailable` phase.
+- **Completing**: After a Pod is created or updated and becomes ready, Kuperator marks its PodOpsLifecycle as the `Completing` phase. During this phase, the Pod is in a ready condition, prompting cooperation controllers to perform actions such as registering the Pod IP in the traffic route. Once all cooperation controllers complete their tasks, Kuperator sets the PodOpsLifecycle to the `ServiceAvailable` phase.
 - **ServiceAvailable**: This phase indicates that the Pod is in a normal state and ready to serve. If everything goes smoothly, the Pod remains in the `ServiceAvailable` phase until the next operation.
 - **Preparing**: When an operation controller needs to operate the Pod, it triggers a new PodOpsLifecycle. The Pod then transitions from the `ServiceAvailable` phase to the `Preparing` phase. During this phase, the Pod is initially marked as Unready by setting ReadinessGate to false. All cooperation controllers then begin preparing tasks, such as removing the Pod's IP from the traffic route. After completing these tasks, the Pod enters the `Operating` phase.
 - **Operating**: If a Pod enters the `Operating` phase, it is expected to accept any kind of operation without any damage, including recreation, scaling-in, upgrading, etc. Operation controllers are permitted to apply any changes to this Pod. Once all these operations are completed, the Pod advances to the next phase — `Completing`, and the PodOpsLifecycle continues.
 
 The PodOpsLifecycle detail and the relationship with Kubernetes native Pod Lifecycle is showed by following sequence diagram.
 
-![pod-ops-lifecycle-sequence-diagram](/img/operating/concepts/podopslifecycle/pod-ops-lifecycle-sequence-diagram.png)
+![pod-ops-lifecycle-sequence-diagram](/img/kuperator/concepts/podopslifecycle/pod-ops-lifecycle-sequence-diagram.png)
 
 ## Developer's Guide
 
 This section introduces how to develop operation controllers and cooperation controllers to interact with PodOpsLifecycle.
-- The operation controller is responsible for a set of Pod operation tasks. KusionStack Operating has already provided various types of operation controllers. Users only need to develop a new operation controller if a new kind of Pod operation needs to be added.
+- The operation controller is responsible for a set of Pod operation tasks. KusionStack Kuperator has already provided various types of operation controllers. Users only need to develop a new operation controller if a new kind of Pod operation needs to be added.
 - The cooperation controller participates in PodOpsLifecycle before and after operating on a Pod, such as the Traffic controller, alert monitoring controller, and other controllers responsible for maintaining the Pod and application status. Users should develop a new cooperation controller only when there is a new type of service or status around the Pod that needs to be maintained, such as integrating with a new traffic provider.
 
 ### Operation Controller
 
-The operation controller is responsible for Pod operations. The tasks that an operation controller needs to perform during PodOpsLifecycle include triggering a PodOpsLifecycle, checking whether the Pod has entered the Operating phase, performing Pod operations, and marking Pod operations as finished. These actions interacting with PodOpsLifecycle are provided in the package `kusionstack.io/operating/pkg/controllers/utils/podopslifecycle/utils.go`.
+The operation controller is responsible for Pod operations. The tasks that an operation controller needs to perform during PodOpsLifecycle include triggering a PodOpsLifecycle, checking whether the Pod has entered the Operating phase, performing Pod operations, and marking Pod operations as finished. These actions interacting with PodOpsLifecycle are provided in the package `kusionstack.io/kuperator/pkg/controllers/utils/podopslifecycle/utils.go`.
 
 A simple operation controller reconcile method would look like this:
 
@@ -53,7 +53,7 @@ import (
     "sigs.k8s.io/controller-runtime/pkg/reconcile"
     "sigs.k8s.io/controller-runtime/pkg/client"
 
-    "kusionstack.io/operating/pkg/controllers/utils/podopslifecycle"
+    "kusionstack.io/kuperator/pkg/controllers/utils/podopslifecycle"
 )
 
 var operationAdapter = &OperationOpsLifecycleAdapter{}
@@ -132,7 +132,7 @@ func (r *PodOperationReconciler) Reconcile(ctx context.Context, req reconcile.Re
 
 There are two ways to develop a cooperation controller. 
 One way is to develop a controller using the controller runtime and adhering to some conventions of PodOpsLifecycle and Kubernetes. 
-Another way is to take the use of [ResourceConsist](https://github.com/KusionStack/resourceconsist) framework provided by KusionStack, which can be referenced from its [documentation](https://www.kusionstack.io/docs/operating/manuals/resourceconsist).
+Another way is to take the use of [ResourceConsist](https://github.com/KusionStack/resourceconsist) framework provided by KusionStack, which can be referenced from its [documentation](https://www.kusionstack.io/docs/kuperator/manuals/resourceconsist).
 
 The following outlines the first approach.
 
@@ -146,14 +146,14 @@ import (
     "sigs.k8s.io/controller-runtime/pkg/controller/controllerutil"
     "sigs.k8s.io/controller-runtime/pkg/reconcile"
 
-    operatingapps "kusionstack.io/operating/apis/apps/v1alpha1"
+    appsv1alpha1 "kusionstack.io/kuperator/apis/apps/v1alpha1"
 )
 
 const (
     // Finalizer needs to have prefix: `prot.podopslifecycle.kusionstack.io`.
-    // KusionStack Operating keeps this prefix back-compatible,
-    // so that it can be hard code to decouple with KusionStack Operating.
-    finalizerPrefix = operatingapps.PodOperationProtectionFinalizerPrefix
+    // KusionStack Kuperator keeps this prefix back-compatible,
+    // so that it can be hard code to decouple with KusionStack Kuperator.
+    finalizerPrefix = appsv1alpha1.PodOperationProtectionFinalizerPrefix
 
     protectionFinalizer = finalizerPrefix + "/" + "unique-id"
 )
@@ -207,15 +207,15 @@ func (r *PodResourceReconciler) removeFinalizer(ctx context.Context, pod *corev1
 
 ### Concurrency Support
 
-PodOpsLifecycle in KusionStack Operating supports concurrency. 
+PodOpsLifecycle in KusionStack Kuperator supports concurrency. 
 It means PodOpsLifecycle is able to organize and track multi controllers operating the same pod at the same time. 
 For example, when a controller is going to update Pod, other controllers are allowed to do other operations at the same time, like delete, restart, recreate it, 
 although the result may not be meaningful.
 
 ### General Workload Support
 
 PodOpsLifecycle offers seamless integration with various workload types, including Deployment and StatefulSet. 
-To enable this functionality, ensure the feature gate for `GraceDeleteWebhook` is enabled when starting the KusionStack Operating controller:
+To enable this functionality, ensure the feature gate for `GraceDeleteWebhook` is enabled when starting the KusionStack Kuperator controller:
 
 ```shell
 # Enable the GraceDeleteWebhook feature when starting the controller with this argument

operating_versioned_docs/version-v0.4/introduction/introduction.md → docs/kuperator/introduction/introduction.md

@@ -1,49 +1,49 @@
-# What is KusionStack Operating?
+# What is KusionStack Kuperator?
 
-KusionStack Operating consists of workloads and operators built on Kubernetes Custom Resource Definitions,
+KusionStack Kuperator consists of workloads and operators built on Kubernetes Custom Resource Definitions,
 with a primary aim of bridging the gap between platform development and Kubernetes.
 
 By keeping more operation works finished in Kubernetes layer,
-KusionStack Operating reduces complexity when interacting with Kubernetes
+KusionStack Kuperator reduces complexity when interacting with Kubernetes
 and enhances convenience for platform developers.
 
 ## Key features
 
-KusionStack Operating currently provides the following features,
+KusionStack Kuperator currently provides the following features,
 streamlining application operations when developing platforms based on Kubernetes:
 
 ### Fine-grained operation
 
-KusionStack Operating introduces PodOpsLifecycle to extend native Pod lifecycle with additional phases such as PreCheck, Preparing, etc. 
-All operators within KusionStack Operating will respect PodOpsLifecycle, 
+KusionStack Kuperator introduces PodOpsLifecycle to extend native Pod lifecycle with additional phases such as PreCheck, Preparing, etc. 
+All operators within KusionStack Kuperator will respect PodOpsLifecycle, 
 so that PodOpsLifecycle is able to orchestrate all of these operators to operate each Pod coordinately. 
 
 ### Advanced workloads
 
-KusionStack Operating offers several workloads to ensure it is convenient and effective to delivery and operate application resources.
+KusionStack Kuperator offers several workloads to ensure it is convenient and effective to delivery and operate application resources.
 
-Recently, Operating provides the workload CollaSet.
+Recently, Kuperator provides the workload CollaSet.
 Besides the basic ability of scaling and updating Pods like Deployment and StatefulSet of Kubernetes,
 CollaSet also provides a range of scale and update strategies,
 like in-place update with container image and pod revision consistency.
 
 ### Streamlined Pod Operation
 
-KusionStack Operating introduces resource consist framework that offers a graceful way 
+KusionStack Kuperator introduces resource consist framework that offers a graceful way 
 to integrate resource management around Pods, including traffic control, into the PodOpsLifecycle.
 This simplifies the works for platform developers dealing with Pod operation details. 
 KusionStack also integrates some resources by default, such as Aliyun SLB.
 
 ### Risk management
 
-Building upon the PodOpsLifecycle, KusionStack Operating introduces the workload named PodTransitionRule
+Building upon the PodOpsLifecycle, KusionStack Kuperator introduces the workload named PodTransitionRule
 which will keep risks of pod operation under control.
 By providing a MaxUnavailable rule similar to Kubernetes' PodDisruptionBudget (PDB),
 it ensures there are always enough Pods available for service.
 Furthermore, it allows for custom rules through extension via webhooks and label hooks.
 
 ## Future works
 
-KusionStack Operating project is currently in its early stages.
+KusionStack Kuperator project is currently in its early stages.
 Our goal is to simplify platform development. We will continue building in areas such as application operations,
-observability, and insight. We hope the Operating will make it easier for you to build platforms.
+observability, and insight. We hope the Kuperator will make it easier for you to build platforms.

operating_versioned_docs/version-v0.3/manuals/collaset.md → docs/kuperator/manuals/collaset.md

@@ -483,7 +483,7 @@ Additionally, the new Pod and old Pod will each begin their own PodOpsLifecycles
 In practice, users often need to recreate or replace specified Pods under a CollaSet.
 
 To delete a Pod, users can simply call the Kubernetes API, like executing `kubectl delete pod <pod-name>`. 
-However, this will bypass the [PodOpsLifecycle](https://www.kusionstack.io/docs/operating/concepts/podopslifecycle) Mechanism. 
+However, this will bypass the [PodOpsLifecycle](https://www.kusionstack.io/docs/kuperator/concepts/podopslifecycle) Mechanism. 
 We provide following two options:
 
 1. Enable the feature `GraceDeleteWebhook` so that it is possible to delete Pods through `PodOpsLifecycle`.

operating_versioned_docs/version-v0.3/manuals/podtransitionrule.md → docs/kuperator/manuals/podtransitionrule.md

@@ -124,7 +124,7 @@ Request:
 // Method: POST
 
 { 
-  "traceId": "<trace-id>",    // <trace-id> is generated by Operating, which can be used to track request
+  "traceId": "<trace-id>",    // <trace-id> is generated by Kuperator, which can be used to track request
   "stage": "PreTrafficOff",
   "ruleName": "webhookCheck",
     "resources": [            // Information of Pods which are in this stage
@@ -165,7 +165,7 @@ Request:
 // Method: POST
 
 { 
-  "traceId": "<trace-id>",    // <trace-id> is generated by Operating, which can be used to track request
+  "traceId": "<trace-id>",    // <trace-id> is generated by Kuperator, which can be used to track request
   "stage": "PreTrafficOff",
   "ruleName": "webhookCheck",
     "resources": [            // Information of Pods which are in this stage