From a0307fa96283f15d6a13f29f1a2bd46e216b155d Mon Sep 17 00:00:00 2001 From: hexin <574252631@qq.com> Date: Mon, 26 Aug 2024 21:27:02 +0800 Subject: [PATCH] rename operating kuperator (#547) * rename operating kuperator * rename operating kuperator1 * rename operating kuperator2 * image url * operating -> kuperator * operating -> kuperator --- README.md | 4 +- .../concepts/_category_.json | 0 .../concepts/podopslifecycle.md | 30 ++++++------ .../introduction/_category_.json | 0 .../kuperator}/introduction/introduction.md | 24 ++++----- .../manuals/_category_.json | 0 .../kuperator}/manuals/collaset.md | 2 +- .../manuals/poddecoration.md | 0 .../kuperator}/manuals/podtransitionrule.md | 4 +- .../manuals/resourceconsist.md | 0 .../started/_category_.json | 0 .../started/demo-graceful-operation.md | 46 +++++++++--------- .../started/install.md | 30 ++++++------ docusaurus.config.js | 22 ++++----- .../current.json | 12 ++--- .../version-v0.3.json | 12 ++--- .../version-v0.4.json | 12 ++--- .../current.json | 12 ++--- .../version-v0.3.json | 12 ++--- .../version-v0.4.json | 12 ++--- .../version-v0.3/concepts/_category_.json | 0 .../version-v0.3}/concepts/podopslifecycle.md | 30 ++++++------ .../version-v0.3/introduction/_category_.json | 0 .../introduction/introduction.md | 24 ++++----- .../version-v0.3/manuals/_category_.json | 0 .../version-v0.3}/manuals/collaset.md | 2 +- .../version-v0.3/manuals/poddecoration.md | 0 .../manuals/podtransitionrule.md | 4 +- .../version-v0.3/manuals/resourceconsist.md | 0 .../version-v0.3/started/_category_.json | 0 .../started/demo-graceful-operation.md | 46 +++++++++--------- .../version-v0.3}/started/install.md | 30 ++++++------ .../version-v0.4/concepts/_category_.json | 0 .../version-v0.4}/concepts/podopslifecycle.md | 30 ++++++------ .../version-v0.4/introduction/_category_.json | 0 .../introduction/introduction.md | 24 ++++----- .../version-v0.4/manuals/_category_.json | 0 .../version-v0.4/manuals/collaset.md | 2 +- .../version-v0.4/manuals/poddecoration.md | 0 .../manuals/podtransitionrule.md | 4 +- .../version-v0.4/manuals/resourceconsist.md | 0 .../version-v0.4/started/_category_.json | 0 .../started/demo-graceful-operation.md | 46 +++++++++--------- .../version-v0.4}/started/install.md | 30 ++++++------ .../version-v0.5/concepts/_category_.json | 0 .../version-v0.5/concepts/podopslifecycle.md | 30 ++++++------ .../version-v0.5/introduction/_category_.json | 0 .../version-v0.5/introduction/introduction.md | 24 ++++----- .../version-v0.5/manuals/_category_.json | 0 .../version-v0.5/manuals/collaset.md | 6 +-- .../version-v0.5/manuals/poddecoration.md | 0 .../manuals/podtransitionrule.md | 4 +- .../version-v0.5/manuals/resourceconsist.md | 0 .../version-v0.5/started/_category_.json | 0 .../started/demo-graceful-operation.md | 46 +++++++++--------- .../version-v0.5}/started/install.md | 30 ++++++------ .../version-v0.3-sidebars.json | 2 +- .../version-v0.4-sidebars.json | 2 +- .../version-v0.5-sidebars.json | 2 +- ...g_versions.json => kuperator_versions.json | 0 sidebars/{operating.js => kuperator.js} | 0 .../pod-ops-lifecycle-sequence-diagram.png | Bin .../podopslifecycle/pod-ops-lifecycle.png | Bin .../collaset/operation-delay-seconds.png | Bin static/{kueperator => kuperator}/index.html | 0 65 files changed, 326 insertions(+), 326 deletions(-) rename docs/{operating => kuperator}/concepts/_category_.json (100%) rename docs/{operating => kuperator}/concepts/podopslifecycle.md (91%) rename docs/{operating => kuperator}/introduction/_category_.json (100%) rename {operating_versioned_docs/version-v0.4 => docs/kuperator}/introduction/introduction.md (70%) rename docs/{operating => kuperator}/manuals/_category_.json (100%) rename {operating_versioned_docs/version-v0.3 => docs/kuperator}/manuals/collaset.md (99%) rename docs/{operating => kuperator}/manuals/poddecoration.md (100%) rename {operating_versioned_docs/version-v0.3 => docs/kuperator}/manuals/podtransitionrule.md (97%) rename docs/{operating => kuperator}/manuals/resourceconsist.md (100%) rename docs/{operating => kuperator}/started/_category_.json (100%) rename {operating_versioned_docs/version-v0.4 => docs/kuperator}/started/demo-graceful-operation.md (88%) rename docs/{operating => kuperator}/started/install.md (50%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.3/concepts/_category_.json (100%) rename {operating_versioned_docs/version-v0.4 => kuperator_versioned_docs/version-v0.3}/concepts/podopslifecycle.md (91%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.3/introduction/_category_.json (100%) rename {docs/operating => kuperator_versioned_docs/version-v0.3}/introduction/introduction.md (70%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.3/manuals/_category_.json (100%) rename {docs/operating => kuperator_versioned_docs/version-v0.3}/manuals/collaset.md (99%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.3/manuals/poddecoration.md (100%) rename {operating_versioned_docs/version-v0.4 => kuperator_versioned_docs/version-v0.3}/manuals/podtransitionrule.md (97%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.3/manuals/resourceconsist.md (100%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.3/started/_category_.json (100%) rename {docs/operating => kuperator_versioned_docs/version-v0.3}/started/demo-graceful-operation.md (88%) rename {operating_versioned_docs/version-v0.4 => kuperator_versioned_docs/version-v0.3}/started/install.md (50%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.4/concepts/_category_.json (100%) rename {operating_versioned_docs/version-v0.3 => kuperator_versioned_docs/version-v0.4}/concepts/podopslifecycle.md (91%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.4/introduction/_category_.json (100%) rename {operating_versioned_docs/version-v0.3 => kuperator_versioned_docs/version-v0.4}/introduction/introduction.md (70%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.4/manuals/_category_.json (100%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.4/manuals/collaset.md (99%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.4/manuals/poddecoration.md (100%) rename {operating_versioned_docs/version-v0.5 => kuperator_versioned_docs/version-v0.4}/manuals/podtransitionrule.md (97%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.4/manuals/resourceconsist.md (100%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.4/started/_category_.json (100%) rename {operating_versioned_docs/version-v0.3 => kuperator_versioned_docs/version-v0.4}/started/demo-graceful-operation.md (88%) rename {operating_versioned_docs/version-v0.5 => kuperator_versioned_docs/version-v0.4}/started/install.md (50%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.5/concepts/_category_.json (100%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.5/concepts/podopslifecycle.md (91%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.5/introduction/_category_.json (100%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.5/introduction/introduction.md (70%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.5/manuals/_category_.json (100%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.5/manuals/collaset.md (99%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.5/manuals/poddecoration.md (100%) rename {docs/operating => kuperator_versioned_docs/version-v0.5}/manuals/podtransitionrule.md (97%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.5/manuals/resourceconsist.md (100%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.5/started/_category_.json (100%) rename {operating_versioned_docs => kuperator_versioned_docs}/version-v0.5/started/demo-graceful-operation.md (88%) rename {operating_versioned_docs/version-v0.3 => kuperator_versioned_docs/version-v0.5}/started/install.md (50%) rename {operating_versioned_sidebars => kuperator_versioned_sidebars}/version-v0.3-sidebars.json (80%) rename {operating_versioned_sidebars => kuperator_versioned_sidebars}/version-v0.4-sidebars.json (81%) rename {operating_versioned_sidebars => kuperator_versioned_sidebars}/version-v0.5-sidebars.json (80%) rename operating_versions.json => kuperator_versions.json (100%) rename sidebars/{operating.js => kuperator.js} (100%) rename static/img/{operating => kuperator}/concepts/podopslifecycle/pod-ops-lifecycle-sequence-diagram.png (100%) rename static/img/{operating => kuperator}/concepts/podopslifecycle/pod-ops-lifecycle.png (100%) rename static/img/{operating => kuperator}/manuals/collaset/operation-delay-seconds.png (100%) rename static/{kueperator => kuperator}/index.html (100%) diff --git a/README.md b/README.md index da32c0e9..3f685137 100644 --- a/README.md +++ b/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` diff --git a/docs/operating/concepts/_category_.json b/docs/kuperator/concepts/_category_.json similarity index 100% rename from docs/operating/concepts/_category_.json rename to docs/kuperator/concepts/_category_.json diff --git a/docs/operating/concepts/podopslifecycle.md b/docs/kuperator/concepts/podopslifecycle.md similarity index 91% rename from docs/operating/concepts/podopslifecycle.md rename to docs/kuperator/concepts/podopslifecycle.md index 7a199c85..88068133 100644 --- a/docs/operating/concepts/podopslifecycle.md +++ b/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,7 +207,7 @@ 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. @@ -215,7 +215,7 @@ 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 diff --git a/docs/operating/introduction/_category_.json b/docs/kuperator/introduction/_category_.json similarity index 100% rename from docs/operating/introduction/_category_.json rename to docs/kuperator/introduction/_category_.json diff --git a/operating_versioned_docs/version-v0.4/introduction/introduction.md b/docs/kuperator/introduction/introduction.md similarity index 70% rename from operating_versioned_docs/version-v0.4/introduction/introduction.md rename to docs/kuperator/introduction/introduction.md index b784f610..5adf228c 100644 --- a/operating_versioned_docs/version-v0.4/introduction/introduction.md +++ b/docs/kuperator/introduction/introduction.md @@ -1,42 +1,42 @@ -# 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. @@ -44,6 +44,6 @@ Furthermore, it allows for custom rules through extension via webhooks and label ## 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. \ No newline at end of file +observability, and insight. We hope the Kuperator will make it easier for you to build platforms. \ No newline at end of file diff --git a/docs/operating/manuals/_category_.json b/docs/kuperator/manuals/_category_.json similarity index 100% rename from docs/operating/manuals/_category_.json rename to docs/kuperator/manuals/_category_.json diff --git a/operating_versioned_docs/version-v0.3/manuals/collaset.md b/docs/kuperator/manuals/collaset.md similarity index 99% rename from operating_versioned_docs/version-v0.3/manuals/collaset.md rename to docs/kuperator/manuals/collaset.md index be4d32cc..b5ebcfaf 100644 --- a/operating_versioned_docs/version-v0.3/manuals/collaset.md +++ b/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 `. -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`. diff --git a/docs/operating/manuals/poddecoration.md b/docs/kuperator/manuals/poddecoration.md similarity index 100% rename from docs/operating/manuals/poddecoration.md rename to docs/kuperator/manuals/poddecoration.md diff --git a/operating_versioned_docs/version-v0.3/manuals/podtransitionrule.md b/docs/kuperator/manuals/podtransitionrule.md similarity index 97% rename from operating_versioned_docs/version-v0.3/manuals/podtransitionrule.md rename to docs/kuperator/manuals/podtransitionrule.md index 9159b674..de0f7d2f 100644 --- a/operating_versioned_docs/version-v0.3/manuals/podtransitionrule.md +++ b/docs/kuperator/manuals/podtransitionrule.md @@ -124,7 +124,7 @@ Request: // Method: POST { - "traceId": "", // is generated by Operating, which can be used to track request + "traceId": "", // 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": "", // is generated by Operating, which can be used to track request + "traceId": "", // is generated by Kuperator, which can be used to track request "stage": "PreTrafficOff", "ruleName": "webhookCheck", "resources": [ // Information of Pods which are in this stage diff --git a/docs/operating/manuals/resourceconsist.md b/docs/kuperator/manuals/resourceconsist.md similarity index 100% rename from docs/operating/manuals/resourceconsist.md rename to docs/kuperator/manuals/resourceconsist.md diff --git a/docs/operating/started/_category_.json b/docs/kuperator/started/_category_.json similarity index 100% rename from docs/operating/started/_category_.json rename to docs/kuperator/started/_category_.json diff --git a/operating_versioned_docs/version-v0.4/started/demo-graceful-operation.md b/docs/kuperator/started/demo-graceful-operation.md similarity index 88% rename from operating_versioned_docs/version-v0.4/started/demo-graceful-operation.md rename to docs/kuperator/started/demo-graceful-operation.md index 741cdde7..6eb1fce9 100644 --- a/operating_versioned_docs/version-v0.4/started/demo-graceful-operation.md +++ b/docs/kuperator/started/demo-graceful-operation.md @@ -1,4 +1,4 @@ -# Using KusionStack Operating to operate Pods gracefully +# Using KusionStack Kuperator to operate Pods gracefully Applications always provide its service along with traffic routing. On Kubernetes, they should be a set of Pods and a corresponding Kubernetes Service resource to expose the service. @@ -6,19 +6,19 @@ On Kubernetes, they should be a set of Pods and a corresponding Kubernetes Servi However, during operations such as updating Pod revisions, there is a risk that client request traffic may be lost. This can lead to a poor user experience for developers. -This tutorial will demonstrate how to operate Pods gracefully in a KusionStack Operating way on Aliyun ACK +This tutorial will demonstrate how to operate Pods gracefully in a KusionStack Kuperator way on Aliyun ACK with SLB as a Service backend provider. > You can also get the same point from [this video](https://www.bilibili.com/video/BV1n8411q7sP/?t=15.7), -> which shows the same case using both KusionStack Kusion and Operating. +> which shows the same case using both KusionStack Kusion and Kuperator. > The sample used in this video can be found from [KusionStack Catalog](https://github.com/KusionStack/catalog/tree/main/models/samples/wordpress). ## Preparing First, ensure that you have an Aliyun ACK Kubernetes cluster set up in order to provision an Aliyun SLB. -Next, install KusionStack Operating on this Kubernetes cluster -following [installation doc](https://kusionstack.io/docs/operating/started/install). +Next, install KusionStack Kuperator on this Kubernetes cluster +following [installation doc](https://kusionstack.io/docs/kuperator/started/install). ## Get started @@ -27,7 +27,7 @@ following [installation doc](https://kusionstack.io/docs/operating/started/insta To begin, create a new namespace for this tutorial: ```shell -$ kubectl create ns operating-tutorial +$ kubectl create ns kuperator-tutorial ``` ### Provision Pods and Services @@ -71,13 +71,13 @@ spec: port: 8080 initialDelaySeconds: 5 periodSeconds: 3 -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` There should be 3 Pods created. ```shell -$ kubectl -n operating-tutorial get pod +$ kubectl -n kuperator-tutorial get pod NAME READY STATUS RESTARTS AGE server-c5lsr 1/1 Running 0 2m23s server-p6wrx 1/1 Running 0 2m23s @@ -106,13 +106,13 @@ spec: selector: app: server type: LoadBalancer -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` A service with external IP should be provisioned. ```shell -$ kubectl -n operating-tutorial get svc server +$ kubectl -n kuperator-tutorial get svc server NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE server LoadBalancer 192.168.225.55 47.101.49.182 80:30146/TCP 51s ``` @@ -154,7 +154,7 @@ spec: - -m - POST - d - - operating-tutorial + - kuperator-tutorial - -qps - "10" - -worker @@ -170,13 +170,13 @@ spec: cpu: "0.1" ephemeral-storage: 1Gi memory: 100Mi -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` A client Pod should be created. ```shell -$ kubectl -n operating-tutorial get pod +$ kubectl -n kuperator-tutorial get pod NAME READY STATUS RESTARTS AGE client-nc426 1/1 Running 0 30s server-c5lsr 1/1 Running 0 19m @@ -188,7 +188,7 @@ This client will continuously access the service using the configuration provide You can monitor the response codes from its logs: ```shell -kubectl -n operating-tutorial logs -f client-nc426 +kubectl -n kuperator-tutorial logs -f client-nc426 worker-0 another loop, request: 50, failed: 0 worker-1 another loop, request: 50, failed: 0 worker-0 another loop, request: 50, failed: 0 @@ -242,7 +242,7 @@ spec: port: 8080 initialDelaySeconds: 5 periodSeconds: 3 -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` It will trigger all Pods updated simultaneously. So the application `server` has no Pod to serve. @@ -279,14 +279,14 @@ spec: selector: matchLabels: app: server -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` After updating the CollaSet of the server to trigger an update, you will see the Pods rolling update one by one, ensuring that at least one Pod is always available to serve. ```shell -kubectl -n operating-tutorial get pod +kubectl -n kuperator-tutorial get pod NAME READY STATUS RESTARTS AGE client-rrfbj 1/1 Running 0 25s server-457sn 0/1 Running 0 5s @@ -315,26 +315,26 @@ worker-0 another loop, request: 50, failed: 0 At the end of this tutorial, you can clean up the resources by deleting the namespace: ```shell -$ kubectl delete ns operating-tutorial +$ kubectl delete ns kuperator-tutorial ``` ## Comparison with the Native Approach Kubernetes provides `preStop` and `postStart` hook in each container, by which users can also interact with service outside -Kubernetes like Aliyun SLB service. However, KusionStack Operating offers several advantages: +Kubernetes like Aliyun SLB service. However, KusionStack Kuperator offers several advantages: * Pod level vs Container level -Operating offers a Pod level hooks which have more complete information than one container, +Kuperator offers a Pod level hooks which have more complete information than one container, especially there are several containers in one Pod. * Plugin-able -Through KusionStack Operating, you can decouple operations executed before or after Pods actually change. +Through KusionStack Kuperator, you can decouple operations executed before or after Pods actually change. For example, traffic control can be added or removed without modifying the Pod's preStop configuration. * Rollback option -In case of issues, rollback becomes a viable option when using the Operating approach to update Pods. -Since Operating does not modify the Pods or their containers during the update, +In case of issues, rollback becomes a viable option when using the Kuperator approach to update Pods. +Since Kuperator does not modify the Pods or their containers during the update, if the traffic service experiences problems, there is an opportunity to cancel the update. \ No newline at end of file diff --git a/docs/operating/started/install.md b/docs/kuperator/started/install.md similarity index 50% rename from docs/operating/started/install.md rename to docs/kuperator/started/install.md index 1f2ba092..1ac6a89c 100644 --- a/docs/operating/started/install.md +++ b/docs/kuperator/started/install.md @@ -5,7 +5,7 @@ sidebar_position: 2 # Installation ## Install with helm -KusionStack Operating requires **Kubernetes version >= 1.18** +KusionStack Kuperator requires **Kubernetes version >= 1.18** ```shell # Firstly add charts repository if you haven't do this. $ helm repo add kusionstack https://kusionstack.github.io/charts @@ -14,7 +14,7 @@ $ helm repo add kusionstack https://kusionstack.github.io/charts $ helm repo update kusionstack # Install the latest version. -$ helm install operating kusionstack/operating +$ helm install kuperator kusionstack/kuperator ``` @@ -25,31 +25,31 @@ The following table lists the configurable parameters of the chart and their def | Parameter | Description | Default | |-------------|----------------|----------------| -| `namespace` | namespace for Operating installation | `kusionstack-system` | +| `namespace` | namespace for Kuperator installation | `kusionstack-system` | | `namespaceEnabled` | Whether to create the installation.namespace | `true` | -| `managerReplicas`| Replicas of Operating deployment | `3` | -| `image.repo` | Repository for operating image | `kusionstack/operating`| -| `image.pullPolicy`| Image pull policy for operating-manager container | `IfNotPresent` | -| `image.tag` | Tag for operating-manager image | `v0.1.0` | -| `resources.limits.cpu` | CPU resource limit of operating-manager container | `500m` | -| `resources.limits.memory` | Memory resource limit of operating-manager container | `128Mi` | -| `resources.requests.cpu` | CPU resource request of operating-manager container | `10m` | -| `resources.requests.memory` | Memory resource request of operating-manager container | `64Mi` | +| `managerReplicas`| Replicas of Kuperator deployment | `3` | +| `image.repo` | Repository for kuperator image | `kusionstack/kuperator`| +| `image.pullPolicy`| Image pull policy for kuperator-manager container | `IfNotPresent` | +| `image.tag` | Tag for kuperator-manager image | `v0.1.0` | +| `resources.limits.cpu` | CPU resource limit of kuperator-manager container | `500m` | +| `resources.limits.memory` | Memory resource limit of kuperator-manager container | `128Mi` | +| `resources.requests.cpu` | CPU resource request of kuperator-manager container | `10m` | +| `resources.requests.memory` | Memory resource request of kuperator-manager container | `64Mi` | ### Upgrade -Run following command to upgrade KusionStack Operating to the latest version. +Run following command to upgrade KusionStack Kuperator to the latest version. ```shell # Upgrade to the latest version -$ helm upgrade operating kusionstack/operating +$ helm upgrade kuperator kusionstack/kuperator ``` ### Uninstall -Run following command to uninstall KusionStack Operating. +Run following command to uninstall KusionStack Kuperator. ```shell # Uninstall -$ helm uninstall operating +$ helm uninstall kuperator ``` \ No newline at end of file diff --git a/docusaurus.config.js b/docusaurus.config.js index 5ab9259a..189bc9f4 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -130,13 +130,13 @@ const config = { [ "@docusaurus/plugin-content-docs", { - id: "operating", - path: "docs/operating", - routeBasePath: "operating", - sidebarPath: "./sidebars/operating.js", + id: "kuperator", + path: "docs/kuperator", + routeBasePath: "kuperator", + sidebarPath: "./sidebars/kuperator.js", versions: { current: { - label: `${getNextVersionName("operating")} 🚧`, + label: `${getNextVersionName("kuperator")} 🚧`, }, }, }, @@ -217,9 +217,9 @@ const config = { { type: "docSidebar", position: "left", - sidebarId: "operating", - label: "Operating", - docsPluginId: "operating", + sidebarId: "kuperator", + label: "Kuperator", + docsPluginId: "kuperator", }, { type: "docSidebar", @@ -254,7 +254,7 @@ const config = { { type: "docsVersionDropdown", position: "right", - docsPluginId: "operating", + docsPluginId: "kuperator", }, { type: "docsVersionDropdown", @@ -294,8 +294,8 @@ const config = { to: "/karpor/", }, { - label: "Operating", - to: "/operating/", + label: "Kuperator", + to: "/kuperator/", }, { label: "CtrlMesh", diff --git a/i18n/en/docusaurus-plugin-content-docs-operating/current.json b/i18n/en/docusaurus-plugin-content-docs-operating/current.json index ab391db9..39507407 100644 --- a/i18n/en/docusaurus-plugin-content-docs-operating/current.json +++ b/i18n/en/docusaurus-plugin-content-docs-operating/current.json @@ -3,16 +3,16 @@ "message": "v0.5 🚧", "description": "The label for version current" }, - "sidebar.operating.category.Getting Started": { + "sidebar.kuperator.category.Getting Started": { "message": "Getting Started", - "description": "The label for category Getting Started in sidebar operating" + "description": "The label for category Getting Started in sidebar kuperator" }, - "sidebar.operating.category.Concepts": { + "sidebar.kuperator.category.Concepts": { "message": "Concepts", - "description": "The label for category Concepts in sidebar operating" + "description": "The label for category Concepts in sidebar kuperator" }, - "sidebar.operating.category.Manuals": { + "sidebar.kuperator.category.Manuals": { "message": "Manuals", - "description": "The label for category Manuals in sidebar operating" + "description": "The label for category Manuals in sidebar kuperator" } } diff --git a/i18n/en/docusaurus-plugin-content-docs-operating/version-v0.3.json b/i18n/en/docusaurus-plugin-content-docs-operating/version-v0.3.json index ddda5f4b..819a0506 100644 --- a/i18n/en/docusaurus-plugin-content-docs-operating/version-v0.3.json +++ b/i18n/en/docusaurus-plugin-content-docs-operating/version-v0.3.json @@ -3,16 +3,16 @@ "message": "v0.3", "description": "The label for version v0.3" }, - "sidebar.operating.category.Getting Started": { + "sidebar.kuperator.category.Getting Started": { "message": "Getting Started", - "description": "The label for category Getting Started in sidebar operating" + "description": "The label for category Getting Started in sidebar kuperator" }, - "sidebar.operating.category.Concepts": { + "sidebar.kuperator.category.Concepts": { "message": "Concepts", - "description": "The label for category Concepts in sidebar operating" + "description": "The label for category Concepts in sidebar kuperator" }, - "sidebar.operating.category.Manuals": { + "sidebar.kuperator.category.Manuals": { "message": "Manuals", - "description": "The label for category Manuals in sidebar operating" + "description": "The label for category Manuals in sidebar kuperator" } } diff --git a/i18n/en/docusaurus-plugin-content-docs-operating/version-v0.4.json b/i18n/en/docusaurus-plugin-content-docs-operating/version-v0.4.json index cfabd55e..ea53bd98 100644 --- a/i18n/en/docusaurus-plugin-content-docs-operating/version-v0.4.json +++ b/i18n/en/docusaurus-plugin-content-docs-operating/version-v0.4.json @@ -3,16 +3,16 @@ "message": "v0.4", "description": "The label for version v0.4" }, - "sidebar.operating.category.Getting Started": { + "sidebar.kuperator.category.Getting Started": { "message": "Getting Started", - "description": "The label for category Getting Started in sidebar operating" + "description": "The label for category Getting Started in sidebar kuperator" }, - "sidebar.operating.category.Concepts": { + "sidebar.kuperator.category.Concepts": { "message": "Concepts", - "description": "The label for category Concepts in sidebar operating" + "description": "The label for category Concepts in sidebar kuperator" }, - "sidebar.operating.category.Manuals": { + "sidebar.kuperator.category.Manuals": { "message": "Manuals", - "description": "The label for category Manuals in sidebar operating" + "description": "The label for category Manuals in sidebar kuperator" } } diff --git a/i18n/zh/docusaurus-plugin-content-docs-operating/current.json b/i18n/zh/docusaurus-plugin-content-docs-operating/current.json index ab391db9..39507407 100644 --- a/i18n/zh/docusaurus-plugin-content-docs-operating/current.json +++ b/i18n/zh/docusaurus-plugin-content-docs-operating/current.json @@ -3,16 +3,16 @@ "message": "v0.5 🚧", "description": "The label for version current" }, - "sidebar.operating.category.Getting Started": { + "sidebar.kuperator.category.Getting Started": { "message": "Getting Started", - "description": "The label for category Getting Started in sidebar operating" + "description": "The label for category Getting Started in sidebar kuperator" }, - "sidebar.operating.category.Concepts": { + "sidebar.kuperator.category.Concepts": { "message": "Concepts", - "description": "The label for category Concepts in sidebar operating" + "description": "The label for category Concepts in sidebar kuperator" }, - "sidebar.operating.category.Manuals": { + "sidebar.kuperator.category.Manuals": { "message": "Manuals", - "description": "The label for category Manuals in sidebar operating" + "description": "The label for category Manuals in sidebar kuperator" } } diff --git a/i18n/zh/docusaurus-plugin-content-docs-operating/version-v0.3.json b/i18n/zh/docusaurus-plugin-content-docs-operating/version-v0.3.json index ddda5f4b..819a0506 100644 --- a/i18n/zh/docusaurus-plugin-content-docs-operating/version-v0.3.json +++ b/i18n/zh/docusaurus-plugin-content-docs-operating/version-v0.3.json @@ -3,16 +3,16 @@ "message": "v0.3", "description": "The label for version v0.3" }, - "sidebar.operating.category.Getting Started": { + "sidebar.kuperator.category.Getting Started": { "message": "Getting Started", - "description": "The label for category Getting Started in sidebar operating" + "description": "The label for category Getting Started in sidebar kuperator" }, - "sidebar.operating.category.Concepts": { + "sidebar.kuperator.category.Concepts": { "message": "Concepts", - "description": "The label for category Concepts in sidebar operating" + "description": "The label for category Concepts in sidebar kuperator" }, - "sidebar.operating.category.Manuals": { + "sidebar.kuperator.category.Manuals": { "message": "Manuals", - "description": "The label for category Manuals in sidebar operating" + "description": "The label for category Manuals in sidebar kuperator" } } diff --git a/i18n/zh/docusaurus-plugin-content-docs-operating/version-v0.4.json b/i18n/zh/docusaurus-plugin-content-docs-operating/version-v0.4.json index cfabd55e..ea53bd98 100644 --- a/i18n/zh/docusaurus-plugin-content-docs-operating/version-v0.4.json +++ b/i18n/zh/docusaurus-plugin-content-docs-operating/version-v0.4.json @@ -3,16 +3,16 @@ "message": "v0.4", "description": "The label for version v0.4" }, - "sidebar.operating.category.Getting Started": { + "sidebar.kuperator.category.Getting Started": { "message": "Getting Started", - "description": "The label for category Getting Started in sidebar operating" + "description": "The label for category Getting Started in sidebar kuperator" }, - "sidebar.operating.category.Concepts": { + "sidebar.kuperator.category.Concepts": { "message": "Concepts", - "description": "The label for category Concepts in sidebar operating" + "description": "The label for category Concepts in sidebar kuperator" }, - "sidebar.operating.category.Manuals": { + "sidebar.kuperator.category.Manuals": { "message": "Manuals", - "description": "The label for category Manuals in sidebar operating" + "description": "The label for category Manuals in sidebar kuperator" } } diff --git a/operating_versioned_docs/version-v0.3/concepts/_category_.json b/kuperator_versioned_docs/version-v0.3/concepts/_category_.json similarity index 100% rename from operating_versioned_docs/version-v0.3/concepts/_category_.json rename to kuperator_versioned_docs/version-v0.3/concepts/_category_.json diff --git a/operating_versioned_docs/version-v0.4/concepts/podopslifecycle.md b/kuperator_versioned_docs/version-v0.3/concepts/podopslifecycle.md similarity index 91% rename from operating_versioned_docs/version-v0.4/concepts/podopslifecycle.md rename to kuperator_versioned_docs/version-v0.3/concepts/podopslifecycle.md index 7a199c85..88068133 100644 --- a/operating_versioned_docs/version-v0.4/concepts/podopslifecycle.md +++ b/kuperator_versioned_docs/version-v0.3/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,7 +207,7 @@ 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. @@ -215,7 +215,7 @@ 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 diff --git a/operating_versioned_docs/version-v0.3/introduction/_category_.json b/kuperator_versioned_docs/version-v0.3/introduction/_category_.json similarity index 100% rename from operating_versioned_docs/version-v0.3/introduction/_category_.json rename to kuperator_versioned_docs/version-v0.3/introduction/_category_.json diff --git a/docs/operating/introduction/introduction.md b/kuperator_versioned_docs/version-v0.3/introduction/introduction.md similarity index 70% rename from docs/operating/introduction/introduction.md rename to kuperator_versioned_docs/version-v0.3/introduction/introduction.md index b784f610..5adf228c 100644 --- a/docs/operating/introduction/introduction.md +++ b/kuperator_versioned_docs/version-v0.3/introduction/introduction.md @@ -1,42 +1,42 @@ -# 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. @@ -44,6 +44,6 @@ Furthermore, it allows for custom rules through extension via webhooks and label ## 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. \ No newline at end of file +observability, and insight. We hope the Kuperator will make it easier for you to build platforms. \ No newline at end of file diff --git a/operating_versioned_docs/version-v0.3/manuals/_category_.json b/kuperator_versioned_docs/version-v0.3/manuals/_category_.json similarity index 100% rename from operating_versioned_docs/version-v0.3/manuals/_category_.json rename to kuperator_versioned_docs/version-v0.3/manuals/_category_.json diff --git a/docs/operating/manuals/collaset.md b/kuperator_versioned_docs/version-v0.3/manuals/collaset.md similarity index 99% rename from docs/operating/manuals/collaset.md rename to kuperator_versioned_docs/version-v0.3/manuals/collaset.md index be4d32cc..b5ebcfaf 100644 --- a/docs/operating/manuals/collaset.md +++ b/kuperator_versioned_docs/version-v0.3/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 `. -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`. diff --git a/operating_versioned_docs/version-v0.3/manuals/poddecoration.md b/kuperator_versioned_docs/version-v0.3/manuals/poddecoration.md similarity index 100% rename from operating_versioned_docs/version-v0.3/manuals/poddecoration.md rename to kuperator_versioned_docs/version-v0.3/manuals/poddecoration.md diff --git a/operating_versioned_docs/version-v0.4/manuals/podtransitionrule.md b/kuperator_versioned_docs/version-v0.3/manuals/podtransitionrule.md similarity index 97% rename from operating_versioned_docs/version-v0.4/manuals/podtransitionrule.md rename to kuperator_versioned_docs/version-v0.3/manuals/podtransitionrule.md index 9159b674..de0f7d2f 100644 --- a/operating_versioned_docs/version-v0.4/manuals/podtransitionrule.md +++ b/kuperator_versioned_docs/version-v0.3/manuals/podtransitionrule.md @@ -124,7 +124,7 @@ Request: // Method: POST { - "traceId": "", // is generated by Operating, which can be used to track request + "traceId": "", // 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": "", // is generated by Operating, which can be used to track request + "traceId": "", // is generated by Kuperator, which can be used to track request "stage": "PreTrafficOff", "ruleName": "webhookCheck", "resources": [ // Information of Pods which are in this stage diff --git a/operating_versioned_docs/version-v0.3/manuals/resourceconsist.md b/kuperator_versioned_docs/version-v0.3/manuals/resourceconsist.md similarity index 100% rename from operating_versioned_docs/version-v0.3/manuals/resourceconsist.md rename to kuperator_versioned_docs/version-v0.3/manuals/resourceconsist.md diff --git a/operating_versioned_docs/version-v0.3/started/_category_.json b/kuperator_versioned_docs/version-v0.3/started/_category_.json similarity index 100% rename from operating_versioned_docs/version-v0.3/started/_category_.json rename to kuperator_versioned_docs/version-v0.3/started/_category_.json diff --git a/docs/operating/started/demo-graceful-operation.md b/kuperator_versioned_docs/version-v0.3/started/demo-graceful-operation.md similarity index 88% rename from docs/operating/started/demo-graceful-operation.md rename to kuperator_versioned_docs/version-v0.3/started/demo-graceful-operation.md index 741cdde7..6eb1fce9 100644 --- a/docs/operating/started/demo-graceful-operation.md +++ b/kuperator_versioned_docs/version-v0.3/started/demo-graceful-operation.md @@ -1,4 +1,4 @@ -# Using KusionStack Operating to operate Pods gracefully +# Using KusionStack Kuperator to operate Pods gracefully Applications always provide its service along with traffic routing. On Kubernetes, they should be a set of Pods and a corresponding Kubernetes Service resource to expose the service. @@ -6,19 +6,19 @@ On Kubernetes, they should be a set of Pods and a corresponding Kubernetes Servi However, during operations such as updating Pod revisions, there is a risk that client request traffic may be lost. This can lead to a poor user experience for developers. -This tutorial will demonstrate how to operate Pods gracefully in a KusionStack Operating way on Aliyun ACK +This tutorial will demonstrate how to operate Pods gracefully in a KusionStack Kuperator way on Aliyun ACK with SLB as a Service backend provider. > You can also get the same point from [this video](https://www.bilibili.com/video/BV1n8411q7sP/?t=15.7), -> which shows the same case using both KusionStack Kusion and Operating. +> which shows the same case using both KusionStack Kusion and Kuperator. > The sample used in this video can be found from [KusionStack Catalog](https://github.com/KusionStack/catalog/tree/main/models/samples/wordpress). ## Preparing First, ensure that you have an Aliyun ACK Kubernetes cluster set up in order to provision an Aliyun SLB. -Next, install KusionStack Operating on this Kubernetes cluster -following [installation doc](https://kusionstack.io/docs/operating/started/install). +Next, install KusionStack Kuperator on this Kubernetes cluster +following [installation doc](https://kusionstack.io/docs/kuperator/started/install). ## Get started @@ -27,7 +27,7 @@ following [installation doc](https://kusionstack.io/docs/operating/started/insta To begin, create a new namespace for this tutorial: ```shell -$ kubectl create ns operating-tutorial +$ kubectl create ns kuperator-tutorial ``` ### Provision Pods and Services @@ -71,13 +71,13 @@ spec: port: 8080 initialDelaySeconds: 5 periodSeconds: 3 -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` There should be 3 Pods created. ```shell -$ kubectl -n operating-tutorial get pod +$ kubectl -n kuperator-tutorial get pod NAME READY STATUS RESTARTS AGE server-c5lsr 1/1 Running 0 2m23s server-p6wrx 1/1 Running 0 2m23s @@ -106,13 +106,13 @@ spec: selector: app: server type: LoadBalancer -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` A service with external IP should be provisioned. ```shell -$ kubectl -n operating-tutorial get svc server +$ kubectl -n kuperator-tutorial get svc server NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE server LoadBalancer 192.168.225.55 47.101.49.182 80:30146/TCP 51s ``` @@ -154,7 +154,7 @@ spec: - -m - POST - d - - operating-tutorial + - kuperator-tutorial - -qps - "10" - -worker @@ -170,13 +170,13 @@ spec: cpu: "0.1" ephemeral-storage: 1Gi memory: 100Mi -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` A client Pod should be created. ```shell -$ kubectl -n operating-tutorial get pod +$ kubectl -n kuperator-tutorial get pod NAME READY STATUS RESTARTS AGE client-nc426 1/1 Running 0 30s server-c5lsr 1/1 Running 0 19m @@ -188,7 +188,7 @@ This client will continuously access the service using the configuration provide You can monitor the response codes from its logs: ```shell -kubectl -n operating-tutorial logs -f client-nc426 +kubectl -n kuperator-tutorial logs -f client-nc426 worker-0 another loop, request: 50, failed: 0 worker-1 another loop, request: 50, failed: 0 worker-0 another loop, request: 50, failed: 0 @@ -242,7 +242,7 @@ spec: port: 8080 initialDelaySeconds: 5 periodSeconds: 3 -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` It will trigger all Pods updated simultaneously. So the application `server` has no Pod to serve. @@ -279,14 +279,14 @@ spec: selector: matchLabels: app: server -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` After updating the CollaSet of the server to trigger an update, you will see the Pods rolling update one by one, ensuring that at least one Pod is always available to serve. ```shell -kubectl -n operating-tutorial get pod +kubectl -n kuperator-tutorial get pod NAME READY STATUS RESTARTS AGE client-rrfbj 1/1 Running 0 25s server-457sn 0/1 Running 0 5s @@ -315,26 +315,26 @@ worker-0 another loop, request: 50, failed: 0 At the end of this tutorial, you can clean up the resources by deleting the namespace: ```shell -$ kubectl delete ns operating-tutorial +$ kubectl delete ns kuperator-tutorial ``` ## Comparison with the Native Approach Kubernetes provides `preStop` and `postStart` hook in each container, by which users can also interact with service outside -Kubernetes like Aliyun SLB service. However, KusionStack Operating offers several advantages: +Kubernetes like Aliyun SLB service. However, KusionStack Kuperator offers several advantages: * Pod level vs Container level -Operating offers a Pod level hooks which have more complete information than one container, +Kuperator offers a Pod level hooks which have more complete information than one container, especially there are several containers in one Pod. * Plugin-able -Through KusionStack Operating, you can decouple operations executed before or after Pods actually change. +Through KusionStack Kuperator, you can decouple operations executed before or after Pods actually change. For example, traffic control can be added or removed without modifying the Pod's preStop configuration. * Rollback option -In case of issues, rollback becomes a viable option when using the Operating approach to update Pods. -Since Operating does not modify the Pods or their containers during the update, +In case of issues, rollback becomes a viable option when using the Kuperator approach to update Pods. +Since Kuperator does not modify the Pods or their containers during the update, if the traffic service experiences problems, there is an opportunity to cancel the update. \ No newline at end of file diff --git a/operating_versioned_docs/version-v0.4/started/install.md b/kuperator_versioned_docs/version-v0.3/started/install.md similarity index 50% rename from operating_versioned_docs/version-v0.4/started/install.md rename to kuperator_versioned_docs/version-v0.3/started/install.md index 1f2ba092..1ac6a89c 100644 --- a/operating_versioned_docs/version-v0.4/started/install.md +++ b/kuperator_versioned_docs/version-v0.3/started/install.md @@ -5,7 +5,7 @@ sidebar_position: 2 # Installation ## Install with helm -KusionStack Operating requires **Kubernetes version >= 1.18** +KusionStack Kuperator requires **Kubernetes version >= 1.18** ```shell # Firstly add charts repository if you haven't do this. $ helm repo add kusionstack https://kusionstack.github.io/charts @@ -14,7 +14,7 @@ $ helm repo add kusionstack https://kusionstack.github.io/charts $ helm repo update kusionstack # Install the latest version. -$ helm install operating kusionstack/operating +$ helm install kuperator kusionstack/kuperator ``` @@ -25,31 +25,31 @@ The following table lists the configurable parameters of the chart and their def | Parameter | Description | Default | |-------------|----------------|----------------| -| `namespace` | namespace for Operating installation | `kusionstack-system` | +| `namespace` | namespace for Kuperator installation | `kusionstack-system` | | `namespaceEnabled` | Whether to create the installation.namespace | `true` | -| `managerReplicas`| Replicas of Operating deployment | `3` | -| `image.repo` | Repository for operating image | `kusionstack/operating`| -| `image.pullPolicy`| Image pull policy for operating-manager container | `IfNotPresent` | -| `image.tag` | Tag for operating-manager image | `v0.1.0` | -| `resources.limits.cpu` | CPU resource limit of operating-manager container | `500m` | -| `resources.limits.memory` | Memory resource limit of operating-manager container | `128Mi` | -| `resources.requests.cpu` | CPU resource request of operating-manager container | `10m` | -| `resources.requests.memory` | Memory resource request of operating-manager container | `64Mi` | +| `managerReplicas`| Replicas of Kuperator deployment | `3` | +| `image.repo` | Repository for kuperator image | `kusionstack/kuperator`| +| `image.pullPolicy`| Image pull policy for kuperator-manager container | `IfNotPresent` | +| `image.tag` | Tag for kuperator-manager image | `v0.1.0` | +| `resources.limits.cpu` | CPU resource limit of kuperator-manager container | `500m` | +| `resources.limits.memory` | Memory resource limit of kuperator-manager container | `128Mi` | +| `resources.requests.cpu` | CPU resource request of kuperator-manager container | `10m` | +| `resources.requests.memory` | Memory resource request of kuperator-manager container | `64Mi` | ### Upgrade -Run following command to upgrade KusionStack Operating to the latest version. +Run following command to upgrade KusionStack Kuperator to the latest version. ```shell # Upgrade to the latest version -$ helm upgrade operating kusionstack/operating +$ helm upgrade kuperator kusionstack/kuperator ``` ### Uninstall -Run following command to uninstall KusionStack Operating. +Run following command to uninstall KusionStack Kuperator. ```shell # Uninstall -$ helm uninstall operating +$ helm uninstall kuperator ``` \ No newline at end of file diff --git a/operating_versioned_docs/version-v0.4/concepts/_category_.json b/kuperator_versioned_docs/version-v0.4/concepts/_category_.json similarity index 100% rename from operating_versioned_docs/version-v0.4/concepts/_category_.json rename to kuperator_versioned_docs/version-v0.4/concepts/_category_.json diff --git a/operating_versioned_docs/version-v0.3/concepts/podopslifecycle.md b/kuperator_versioned_docs/version-v0.4/concepts/podopslifecycle.md similarity index 91% rename from operating_versioned_docs/version-v0.3/concepts/podopslifecycle.md rename to kuperator_versioned_docs/version-v0.4/concepts/podopslifecycle.md index 7a199c85..88068133 100644 --- a/operating_versioned_docs/version-v0.3/concepts/podopslifecycle.md +++ b/kuperator_versioned_docs/version-v0.4/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,7 +207,7 @@ 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. @@ -215,7 +215,7 @@ 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 diff --git a/operating_versioned_docs/version-v0.4/introduction/_category_.json b/kuperator_versioned_docs/version-v0.4/introduction/_category_.json similarity index 100% rename from operating_versioned_docs/version-v0.4/introduction/_category_.json rename to kuperator_versioned_docs/version-v0.4/introduction/_category_.json diff --git a/operating_versioned_docs/version-v0.3/introduction/introduction.md b/kuperator_versioned_docs/version-v0.4/introduction/introduction.md similarity index 70% rename from operating_versioned_docs/version-v0.3/introduction/introduction.md rename to kuperator_versioned_docs/version-v0.4/introduction/introduction.md index b784f610..5adf228c 100644 --- a/operating_versioned_docs/version-v0.3/introduction/introduction.md +++ b/kuperator_versioned_docs/version-v0.4/introduction/introduction.md @@ -1,42 +1,42 @@ -# 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. @@ -44,6 +44,6 @@ Furthermore, it allows for custom rules through extension via webhooks and label ## 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. \ No newline at end of file +observability, and insight. We hope the Kuperator will make it easier for you to build platforms. \ No newline at end of file diff --git a/operating_versioned_docs/version-v0.4/manuals/_category_.json b/kuperator_versioned_docs/version-v0.4/manuals/_category_.json similarity index 100% rename from operating_versioned_docs/version-v0.4/manuals/_category_.json rename to kuperator_versioned_docs/version-v0.4/manuals/_category_.json diff --git a/operating_versioned_docs/version-v0.4/manuals/collaset.md b/kuperator_versioned_docs/version-v0.4/manuals/collaset.md similarity index 99% rename from operating_versioned_docs/version-v0.4/manuals/collaset.md rename to kuperator_versioned_docs/version-v0.4/manuals/collaset.md index 30177301..620fb9c6 100644 --- a/operating_versioned_docs/version-v0.4/manuals/collaset.md +++ b/kuperator_versioned_docs/version-v0.4/manuals/collaset.md @@ -513,7 +513,7 @@ $ /manager --feature-gates=ReclaimPodToDelete=false 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 `. -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`. diff --git a/operating_versioned_docs/version-v0.4/manuals/poddecoration.md b/kuperator_versioned_docs/version-v0.4/manuals/poddecoration.md similarity index 100% rename from operating_versioned_docs/version-v0.4/manuals/poddecoration.md rename to kuperator_versioned_docs/version-v0.4/manuals/poddecoration.md diff --git a/operating_versioned_docs/version-v0.5/manuals/podtransitionrule.md b/kuperator_versioned_docs/version-v0.4/manuals/podtransitionrule.md similarity index 97% rename from operating_versioned_docs/version-v0.5/manuals/podtransitionrule.md rename to kuperator_versioned_docs/version-v0.4/manuals/podtransitionrule.md index 9159b674..de0f7d2f 100644 --- a/operating_versioned_docs/version-v0.5/manuals/podtransitionrule.md +++ b/kuperator_versioned_docs/version-v0.4/manuals/podtransitionrule.md @@ -124,7 +124,7 @@ Request: // Method: POST { - "traceId": "", // is generated by Operating, which can be used to track request + "traceId": "", // 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": "", // is generated by Operating, which can be used to track request + "traceId": "", // is generated by Kuperator, which can be used to track request "stage": "PreTrafficOff", "ruleName": "webhookCheck", "resources": [ // Information of Pods which are in this stage diff --git a/operating_versioned_docs/version-v0.4/manuals/resourceconsist.md b/kuperator_versioned_docs/version-v0.4/manuals/resourceconsist.md similarity index 100% rename from operating_versioned_docs/version-v0.4/manuals/resourceconsist.md rename to kuperator_versioned_docs/version-v0.4/manuals/resourceconsist.md diff --git a/operating_versioned_docs/version-v0.4/started/_category_.json b/kuperator_versioned_docs/version-v0.4/started/_category_.json similarity index 100% rename from operating_versioned_docs/version-v0.4/started/_category_.json rename to kuperator_versioned_docs/version-v0.4/started/_category_.json diff --git a/operating_versioned_docs/version-v0.3/started/demo-graceful-operation.md b/kuperator_versioned_docs/version-v0.4/started/demo-graceful-operation.md similarity index 88% rename from operating_versioned_docs/version-v0.3/started/demo-graceful-operation.md rename to kuperator_versioned_docs/version-v0.4/started/demo-graceful-operation.md index 741cdde7..6eb1fce9 100644 --- a/operating_versioned_docs/version-v0.3/started/demo-graceful-operation.md +++ b/kuperator_versioned_docs/version-v0.4/started/demo-graceful-operation.md @@ -1,4 +1,4 @@ -# Using KusionStack Operating to operate Pods gracefully +# Using KusionStack Kuperator to operate Pods gracefully Applications always provide its service along with traffic routing. On Kubernetes, they should be a set of Pods and a corresponding Kubernetes Service resource to expose the service. @@ -6,19 +6,19 @@ On Kubernetes, they should be a set of Pods and a corresponding Kubernetes Servi However, during operations such as updating Pod revisions, there is a risk that client request traffic may be lost. This can lead to a poor user experience for developers. -This tutorial will demonstrate how to operate Pods gracefully in a KusionStack Operating way on Aliyun ACK +This tutorial will demonstrate how to operate Pods gracefully in a KusionStack Kuperator way on Aliyun ACK with SLB as a Service backend provider. > You can also get the same point from [this video](https://www.bilibili.com/video/BV1n8411q7sP/?t=15.7), -> which shows the same case using both KusionStack Kusion and Operating. +> which shows the same case using both KusionStack Kusion and Kuperator. > The sample used in this video can be found from [KusionStack Catalog](https://github.com/KusionStack/catalog/tree/main/models/samples/wordpress). ## Preparing First, ensure that you have an Aliyun ACK Kubernetes cluster set up in order to provision an Aliyun SLB. -Next, install KusionStack Operating on this Kubernetes cluster -following [installation doc](https://kusionstack.io/docs/operating/started/install). +Next, install KusionStack Kuperator on this Kubernetes cluster +following [installation doc](https://kusionstack.io/docs/kuperator/started/install). ## Get started @@ -27,7 +27,7 @@ following [installation doc](https://kusionstack.io/docs/operating/started/insta To begin, create a new namespace for this tutorial: ```shell -$ kubectl create ns operating-tutorial +$ kubectl create ns kuperator-tutorial ``` ### Provision Pods and Services @@ -71,13 +71,13 @@ spec: port: 8080 initialDelaySeconds: 5 periodSeconds: 3 -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` There should be 3 Pods created. ```shell -$ kubectl -n operating-tutorial get pod +$ kubectl -n kuperator-tutorial get pod NAME READY STATUS RESTARTS AGE server-c5lsr 1/1 Running 0 2m23s server-p6wrx 1/1 Running 0 2m23s @@ -106,13 +106,13 @@ spec: selector: app: server type: LoadBalancer -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` A service with external IP should be provisioned. ```shell -$ kubectl -n operating-tutorial get svc server +$ kubectl -n kuperator-tutorial get svc server NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE server LoadBalancer 192.168.225.55 47.101.49.182 80:30146/TCP 51s ``` @@ -154,7 +154,7 @@ spec: - -m - POST - d - - operating-tutorial + - kuperator-tutorial - -qps - "10" - -worker @@ -170,13 +170,13 @@ spec: cpu: "0.1" ephemeral-storage: 1Gi memory: 100Mi -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` A client Pod should be created. ```shell -$ kubectl -n operating-tutorial get pod +$ kubectl -n kuperator-tutorial get pod NAME READY STATUS RESTARTS AGE client-nc426 1/1 Running 0 30s server-c5lsr 1/1 Running 0 19m @@ -188,7 +188,7 @@ This client will continuously access the service using the configuration provide You can monitor the response codes from its logs: ```shell -kubectl -n operating-tutorial logs -f client-nc426 +kubectl -n kuperator-tutorial logs -f client-nc426 worker-0 another loop, request: 50, failed: 0 worker-1 another loop, request: 50, failed: 0 worker-0 another loop, request: 50, failed: 0 @@ -242,7 +242,7 @@ spec: port: 8080 initialDelaySeconds: 5 periodSeconds: 3 -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` It will trigger all Pods updated simultaneously. So the application `server` has no Pod to serve. @@ -279,14 +279,14 @@ spec: selector: matchLabels: app: server -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` After updating the CollaSet of the server to trigger an update, you will see the Pods rolling update one by one, ensuring that at least one Pod is always available to serve. ```shell -kubectl -n operating-tutorial get pod +kubectl -n kuperator-tutorial get pod NAME READY STATUS RESTARTS AGE client-rrfbj 1/1 Running 0 25s server-457sn 0/1 Running 0 5s @@ -315,26 +315,26 @@ worker-0 another loop, request: 50, failed: 0 At the end of this tutorial, you can clean up the resources by deleting the namespace: ```shell -$ kubectl delete ns operating-tutorial +$ kubectl delete ns kuperator-tutorial ``` ## Comparison with the Native Approach Kubernetes provides `preStop` and `postStart` hook in each container, by which users can also interact with service outside -Kubernetes like Aliyun SLB service. However, KusionStack Operating offers several advantages: +Kubernetes like Aliyun SLB service. However, KusionStack Kuperator offers several advantages: * Pod level vs Container level -Operating offers a Pod level hooks which have more complete information than one container, +Kuperator offers a Pod level hooks which have more complete information than one container, especially there are several containers in one Pod. * Plugin-able -Through KusionStack Operating, you can decouple operations executed before or after Pods actually change. +Through KusionStack Kuperator, you can decouple operations executed before or after Pods actually change. For example, traffic control can be added or removed without modifying the Pod's preStop configuration. * Rollback option -In case of issues, rollback becomes a viable option when using the Operating approach to update Pods. -Since Operating does not modify the Pods or their containers during the update, +In case of issues, rollback becomes a viable option when using the Kuperator approach to update Pods. +Since Kuperator does not modify the Pods or their containers during the update, if the traffic service experiences problems, there is an opportunity to cancel the update. \ No newline at end of file diff --git a/operating_versioned_docs/version-v0.5/started/install.md b/kuperator_versioned_docs/version-v0.4/started/install.md similarity index 50% rename from operating_versioned_docs/version-v0.5/started/install.md rename to kuperator_versioned_docs/version-v0.4/started/install.md index 1f2ba092..1ac6a89c 100644 --- a/operating_versioned_docs/version-v0.5/started/install.md +++ b/kuperator_versioned_docs/version-v0.4/started/install.md @@ -5,7 +5,7 @@ sidebar_position: 2 # Installation ## Install with helm -KusionStack Operating requires **Kubernetes version >= 1.18** +KusionStack Kuperator requires **Kubernetes version >= 1.18** ```shell # Firstly add charts repository if you haven't do this. $ helm repo add kusionstack https://kusionstack.github.io/charts @@ -14,7 +14,7 @@ $ helm repo add kusionstack https://kusionstack.github.io/charts $ helm repo update kusionstack # Install the latest version. -$ helm install operating kusionstack/operating +$ helm install kuperator kusionstack/kuperator ``` @@ -25,31 +25,31 @@ The following table lists the configurable parameters of the chart and their def | Parameter | Description | Default | |-------------|----------------|----------------| -| `namespace` | namespace for Operating installation | `kusionstack-system` | +| `namespace` | namespace for Kuperator installation | `kusionstack-system` | | `namespaceEnabled` | Whether to create the installation.namespace | `true` | -| `managerReplicas`| Replicas of Operating deployment | `3` | -| `image.repo` | Repository for operating image | `kusionstack/operating`| -| `image.pullPolicy`| Image pull policy for operating-manager container | `IfNotPresent` | -| `image.tag` | Tag for operating-manager image | `v0.1.0` | -| `resources.limits.cpu` | CPU resource limit of operating-manager container | `500m` | -| `resources.limits.memory` | Memory resource limit of operating-manager container | `128Mi` | -| `resources.requests.cpu` | CPU resource request of operating-manager container | `10m` | -| `resources.requests.memory` | Memory resource request of operating-manager container | `64Mi` | +| `managerReplicas`| Replicas of Kuperator deployment | `3` | +| `image.repo` | Repository for kuperator image | `kusionstack/kuperator`| +| `image.pullPolicy`| Image pull policy for kuperator-manager container | `IfNotPresent` | +| `image.tag` | Tag for kuperator-manager image | `v0.1.0` | +| `resources.limits.cpu` | CPU resource limit of kuperator-manager container | `500m` | +| `resources.limits.memory` | Memory resource limit of kuperator-manager container | `128Mi` | +| `resources.requests.cpu` | CPU resource request of kuperator-manager container | `10m` | +| `resources.requests.memory` | Memory resource request of kuperator-manager container | `64Mi` | ### Upgrade -Run following command to upgrade KusionStack Operating to the latest version. +Run following command to upgrade KusionStack Kuperator to the latest version. ```shell # Upgrade to the latest version -$ helm upgrade operating kusionstack/operating +$ helm upgrade kuperator kusionstack/kuperator ``` ### Uninstall -Run following command to uninstall KusionStack Operating. +Run following command to uninstall KusionStack Kuperator. ```shell # Uninstall -$ helm uninstall operating +$ helm uninstall kuperator ``` \ No newline at end of file diff --git a/operating_versioned_docs/version-v0.5/concepts/_category_.json b/kuperator_versioned_docs/version-v0.5/concepts/_category_.json similarity index 100% rename from operating_versioned_docs/version-v0.5/concepts/_category_.json rename to kuperator_versioned_docs/version-v0.5/concepts/_category_.json diff --git a/operating_versioned_docs/version-v0.5/concepts/podopslifecycle.md b/kuperator_versioned_docs/version-v0.5/concepts/podopslifecycle.md similarity index 91% rename from operating_versioned_docs/version-v0.5/concepts/podopslifecycle.md rename to kuperator_versioned_docs/version-v0.5/concepts/podopslifecycle.md index 7a199c85..88068133 100644 --- a/operating_versioned_docs/version-v0.5/concepts/podopslifecycle.md +++ b/kuperator_versioned_docs/version-v0.5/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,7 +207,7 @@ 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. @@ -215,7 +215,7 @@ 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 diff --git a/operating_versioned_docs/version-v0.5/introduction/_category_.json b/kuperator_versioned_docs/version-v0.5/introduction/_category_.json similarity index 100% rename from operating_versioned_docs/version-v0.5/introduction/_category_.json rename to kuperator_versioned_docs/version-v0.5/introduction/_category_.json diff --git a/operating_versioned_docs/version-v0.5/introduction/introduction.md b/kuperator_versioned_docs/version-v0.5/introduction/introduction.md similarity index 70% rename from operating_versioned_docs/version-v0.5/introduction/introduction.md rename to kuperator_versioned_docs/version-v0.5/introduction/introduction.md index b784f610..5adf228c 100644 --- a/operating_versioned_docs/version-v0.5/introduction/introduction.md +++ b/kuperator_versioned_docs/version-v0.5/introduction/introduction.md @@ -1,42 +1,42 @@ -# 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. @@ -44,6 +44,6 @@ Furthermore, it allows for custom rules through extension via webhooks and label ## 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. \ No newline at end of file +observability, and insight. We hope the Kuperator will make it easier for you to build platforms. \ No newline at end of file diff --git a/operating_versioned_docs/version-v0.5/manuals/_category_.json b/kuperator_versioned_docs/version-v0.5/manuals/_category_.json similarity index 100% rename from operating_versioned_docs/version-v0.5/manuals/_category_.json rename to kuperator_versioned_docs/version-v0.5/manuals/_category_.json diff --git a/operating_versioned_docs/version-v0.5/manuals/collaset.md b/kuperator_versioned_docs/version-v0.5/manuals/collaset.md similarity index 99% rename from operating_versioned_docs/version-v0.5/manuals/collaset.md rename to kuperator_versioned_docs/version-v0.5/manuals/collaset.md index 6bc5dde6..6e1aaddf 100644 --- a/operating_versioned_docs/version-v0.5/manuals/collaset.md +++ b/kuperator_versioned_docs/version-v0.5/manuals/collaset.md @@ -489,7 +489,7 @@ spec: operationDelaySeconds: 60 # duration between traffic off and container shutdown ``` -In pod operations, including scaling down, updates, and deletions, [PodOpsLifecycle](http://localhost:3000/operating/concepts/podopslifecycle) is responsible for managing the full lifecycle of pods (e.g., `ServiceAvailable`, `Preparing`, `Operating` and `Completing`). +In pod operations, including scaling down, updates, and deletions, [PodOpsLifecycle](http://localhost:3000/kuperator/concepts/podopslifecycle) is responsible for managing the full lifecycle of pods (e.g., `ServiceAvailable`, `Preparing`, `Operating` and `Completing`). These operations involve shutting down or restarting containers. Directly shutting down containers after traffic off can lead to situations where long connection requests become unresponsive. @@ -499,7 +499,7 @@ During this period, it is expected to close the containers after waiting for som The `operationDelaySeconds` serves a purpose similar to the `terminationGracePeriodSeconds` on a pod. However, the difference is that since operationDelaySeconds is configured in the Spec of CollaSet, modifications to this setting will not trigger pod upgrade. -![operation-delay-seconds](/img/operating/manuals/collaset/operation-delay-seconds.png) +![operation-delay-seconds](/img/kuperator/manuals/collaset/operation-delay-seconds.png) Note that if both operationDelaySeconds and terminationGracePeriodSeconds fields are configured simultaneously, after the traffic off, the user application may wait (operationDelaySeconds + terminationGracePeriodSeconds) before the container being shutdown. @@ -537,7 +537,7 @@ $ /manager --feature-gates=ReclaimPodToDelete=false 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 `. -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`. diff --git a/operating_versioned_docs/version-v0.5/manuals/poddecoration.md b/kuperator_versioned_docs/version-v0.5/manuals/poddecoration.md similarity index 100% rename from operating_versioned_docs/version-v0.5/manuals/poddecoration.md rename to kuperator_versioned_docs/version-v0.5/manuals/poddecoration.md diff --git a/docs/operating/manuals/podtransitionrule.md b/kuperator_versioned_docs/version-v0.5/manuals/podtransitionrule.md similarity index 97% rename from docs/operating/manuals/podtransitionrule.md rename to kuperator_versioned_docs/version-v0.5/manuals/podtransitionrule.md index 9159b674..de0f7d2f 100644 --- a/docs/operating/manuals/podtransitionrule.md +++ b/kuperator_versioned_docs/version-v0.5/manuals/podtransitionrule.md @@ -124,7 +124,7 @@ Request: // Method: POST { - "traceId": "", // is generated by Operating, which can be used to track request + "traceId": "", // 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": "", // is generated by Operating, which can be used to track request + "traceId": "", // is generated by Kuperator, which can be used to track request "stage": "PreTrafficOff", "ruleName": "webhookCheck", "resources": [ // Information of Pods which are in this stage diff --git a/operating_versioned_docs/version-v0.5/manuals/resourceconsist.md b/kuperator_versioned_docs/version-v0.5/manuals/resourceconsist.md similarity index 100% rename from operating_versioned_docs/version-v0.5/manuals/resourceconsist.md rename to kuperator_versioned_docs/version-v0.5/manuals/resourceconsist.md diff --git a/operating_versioned_docs/version-v0.5/started/_category_.json b/kuperator_versioned_docs/version-v0.5/started/_category_.json similarity index 100% rename from operating_versioned_docs/version-v0.5/started/_category_.json rename to kuperator_versioned_docs/version-v0.5/started/_category_.json diff --git a/operating_versioned_docs/version-v0.5/started/demo-graceful-operation.md b/kuperator_versioned_docs/version-v0.5/started/demo-graceful-operation.md similarity index 88% rename from operating_versioned_docs/version-v0.5/started/demo-graceful-operation.md rename to kuperator_versioned_docs/version-v0.5/started/demo-graceful-operation.md index 741cdde7..6eb1fce9 100644 --- a/operating_versioned_docs/version-v0.5/started/demo-graceful-operation.md +++ b/kuperator_versioned_docs/version-v0.5/started/demo-graceful-operation.md @@ -1,4 +1,4 @@ -# Using KusionStack Operating to operate Pods gracefully +# Using KusionStack Kuperator to operate Pods gracefully Applications always provide its service along with traffic routing. On Kubernetes, they should be a set of Pods and a corresponding Kubernetes Service resource to expose the service. @@ -6,19 +6,19 @@ On Kubernetes, they should be a set of Pods and a corresponding Kubernetes Servi However, during operations such as updating Pod revisions, there is a risk that client request traffic may be lost. This can lead to a poor user experience for developers. -This tutorial will demonstrate how to operate Pods gracefully in a KusionStack Operating way on Aliyun ACK +This tutorial will demonstrate how to operate Pods gracefully in a KusionStack Kuperator way on Aliyun ACK with SLB as a Service backend provider. > You can also get the same point from [this video](https://www.bilibili.com/video/BV1n8411q7sP/?t=15.7), -> which shows the same case using both KusionStack Kusion and Operating. +> which shows the same case using both KusionStack Kusion and Kuperator. > The sample used in this video can be found from [KusionStack Catalog](https://github.com/KusionStack/catalog/tree/main/models/samples/wordpress). ## Preparing First, ensure that you have an Aliyun ACK Kubernetes cluster set up in order to provision an Aliyun SLB. -Next, install KusionStack Operating on this Kubernetes cluster -following [installation doc](https://kusionstack.io/docs/operating/started/install). +Next, install KusionStack Kuperator on this Kubernetes cluster +following [installation doc](https://kusionstack.io/docs/kuperator/started/install). ## Get started @@ -27,7 +27,7 @@ following [installation doc](https://kusionstack.io/docs/operating/started/insta To begin, create a new namespace for this tutorial: ```shell -$ kubectl create ns operating-tutorial +$ kubectl create ns kuperator-tutorial ``` ### Provision Pods and Services @@ -71,13 +71,13 @@ spec: port: 8080 initialDelaySeconds: 5 periodSeconds: 3 -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` There should be 3 Pods created. ```shell -$ kubectl -n operating-tutorial get pod +$ kubectl -n kuperator-tutorial get pod NAME READY STATUS RESTARTS AGE server-c5lsr 1/1 Running 0 2m23s server-p6wrx 1/1 Running 0 2m23s @@ -106,13 +106,13 @@ spec: selector: app: server type: LoadBalancer -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` A service with external IP should be provisioned. ```shell -$ kubectl -n operating-tutorial get svc server +$ kubectl -n kuperator-tutorial get svc server NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE server LoadBalancer 192.168.225.55 47.101.49.182 80:30146/TCP 51s ``` @@ -154,7 +154,7 @@ spec: - -m - POST - d - - operating-tutorial + - kuperator-tutorial - -qps - "10" - -worker @@ -170,13 +170,13 @@ spec: cpu: "0.1" ephemeral-storage: 1Gi memory: 100Mi -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` A client Pod should be created. ```shell -$ kubectl -n operating-tutorial get pod +$ kubectl -n kuperator-tutorial get pod NAME READY STATUS RESTARTS AGE client-nc426 1/1 Running 0 30s server-c5lsr 1/1 Running 0 19m @@ -188,7 +188,7 @@ This client will continuously access the service using the configuration provide You can monitor the response codes from its logs: ```shell -kubectl -n operating-tutorial logs -f client-nc426 +kubectl -n kuperator-tutorial logs -f client-nc426 worker-0 another loop, request: 50, failed: 0 worker-1 another loop, request: 50, failed: 0 worker-0 another loop, request: 50, failed: 0 @@ -242,7 +242,7 @@ spec: port: 8080 initialDelaySeconds: 5 periodSeconds: 3 -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` It will trigger all Pods updated simultaneously. So the application `server` has no Pod to serve. @@ -279,14 +279,14 @@ spec: selector: matchLabels: app: server -' | kubectl -n operating-tutorial apply -f - +' | kubectl -n kuperator-tutorial apply -f - ``` After updating the CollaSet of the server to trigger an update, you will see the Pods rolling update one by one, ensuring that at least one Pod is always available to serve. ```shell -kubectl -n operating-tutorial get pod +kubectl -n kuperator-tutorial get pod NAME READY STATUS RESTARTS AGE client-rrfbj 1/1 Running 0 25s server-457sn 0/1 Running 0 5s @@ -315,26 +315,26 @@ worker-0 another loop, request: 50, failed: 0 At the end of this tutorial, you can clean up the resources by deleting the namespace: ```shell -$ kubectl delete ns operating-tutorial +$ kubectl delete ns kuperator-tutorial ``` ## Comparison with the Native Approach Kubernetes provides `preStop` and `postStart` hook in each container, by which users can also interact with service outside -Kubernetes like Aliyun SLB service. However, KusionStack Operating offers several advantages: +Kubernetes like Aliyun SLB service. However, KusionStack Kuperator offers several advantages: * Pod level vs Container level -Operating offers a Pod level hooks which have more complete information than one container, +Kuperator offers a Pod level hooks which have more complete information than one container, especially there are several containers in one Pod. * Plugin-able -Through KusionStack Operating, you can decouple operations executed before or after Pods actually change. +Through KusionStack Kuperator, you can decouple operations executed before or after Pods actually change. For example, traffic control can be added or removed without modifying the Pod's preStop configuration. * Rollback option -In case of issues, rollback becomes a viable option when using the Operating approach to update Pods. -Since Operating does not modify the Pods or their containers during the update, +In case of issues, rollback becomes a viable option when using the Kuperator approach to update Pods. +Since Kuperator does not modify the Pods or their containers during the update, if the traffic service experiences problems, there is an opportunity to cancel the update. \ No newline at end of file diff --git a/operating_versioned_docs/version-v0.3/started/install.md b/kuperator_versioned_docs/version-v0.5/started/install.md similarity index 50% rename from operating_versioned_docs/version-v0.3/started/install.md rename to kuperator_versioned_docs/version-v0.5/started/install.md index 1f2ba092..1ac6a89c 100644 --- a/operating_versioned_docs/version-v0.3/started/install.md +++ b/kuperator_versioned_docs/version-v0.5/started/install.md @@ -5,7 +5,7 @@ sidebar_position: 2 # Installation ## Install with helm -KusionStack Operating requires **Kubernetes version >= 1.18** +KusionStack Kuperator requires **Kubernetes version >= 1.18** ```shell # Firstly add charts repository if you haven't do this. $ helm repo add kusionstack https://kusionstack.github.io/charts @@ -14,7 +14,7 @@ $ helm repo add kusionstack https://kusionstack.github.io/charts $ helm repo update kusionstack # Install the latest version. -$ helm install operating kusionstack/operating +$ helm install kuperator kusionstack/kuperator ``` @@ -25,31 +25,31 @@ The following table lists the configurable parameters of the chart and their def | Parameter | Description | Default | |-------------|----------------|----------------| -| `namespace` | namespace for Operating installation | `kusionstack-system` | +| `namespace` | namespace for Kuperator installation | `kusionstack-system` | | `namespaceEnabled` | Whether to create the installation.namespace | `true` | -| `managerReplicas`| Replicas of Operating deployment | `3` | -| `image.repo` | Repository for operating image | `kusionstack/operating`| -| `image.pullPolicy`| Image pull policy for operating-manager container | `IfNotPresent` | -| `image.tag` | Tag for operating-manager image | `v0.1.0` | -| `resources.limits.cpu` | CPU resource limit of operating-manager container | `500m` | -| `resources.limits.memory` | Memory resource limit of operating-manager container | `128Mi` | -| `resources.requests.cpu` | CPU resource request of operating-manager container | `10m` | -| `resources.requests.memory` | Memory resource request of operating-manager container | `64Mi` | +| `managerReplicas`| Replicas of Kuperator deployment | `3` | +| `image.repo` | Repository for kuperator image | `kusionstack/kuperator`| +| `image.pullPolicy`| Image pull policy for kuperator-manager container | `IfNotPresent` | +| `image.tag` | Tag for kuperator-manager image | `v0.1.0` | +| `resources.limits.cpu` | CPU resource limit of kuperator-manager container | `500m` | +| `resources.limits.memory` | Memory resource limit of kuperator-manager container | `128Mi` | +| `resources.requests.cpu` | CPU resource request of kuperator-manager container | `10m` | +| `resources.requests.memory` | Memory resource request of kuperator-manager container | `64Mi` | ### Upgrade -Run following command to upgrade KusionStack Operating to the latest version. +Run following command to upgrade KusionStack Kuperator to the latest version. ```shell # Upgrade to the latest version -$ helm upgrade operating kusionstack/operating +$ helm upgrade kuperator kusionstack/kuperator ``` ### Uninstall -Run following command to uninstall KusionStack Operating. +Run following command to uninstall KusionStack Kuperator. ```shell # Uninstall -$ helm uninstall operating +$ helm uninstall kuperator ``` \ No newline at end of file diff --git a/operating_versioned_sidebars/version-v0.3-sidebars.json b/kuperator_versioned_sidebars/version-v0.3-sidebars.json similarity index 80% rename from operating_versioned_sidebars/version-v0.3-sidebars.json rename to kuperator_versioned_sidebars/version-v0.3-sidebars.json index 91fbd4d5..f12156e2 100644 --- a/operating_versioned_sidebars/version-v0.3-sidebars.json +++ b/kuperator_versioned_sidebars/version-v0.3-sidebars.json @@ -1,5 +1,5 @@ { - "operating": [ + "kuperator": [ { "type": "autogenerated", "dirName": "." diff --git a/operating_versioned_sidebars/version-v0.4-sidebars.json b/kuperator_versioned_sidebars/version-v0.4-sidebars.json similarity index 81% rename from operating_versioned_sidebars/version-v0.4-sidebars.json rename to kuperator_versioned_sidebars/version-v0.4-sidebars.json index 9fdc5061..fb5f7e08 100644 --- a/operating_versioned_sidebars/version-v0.4-sidebars.json +++ b/kuperator_versioned_sidebars/version-v0.4-sidebars.json @@ -1,5 +1,5 @@ { - "operating": [ + "kuperator": [ { "type": "autogenerated", "dirName": "." diff --git a/operating_versioned_sidebars/version-v0.5-sidebars.json b/kuperator_versioned_sidebars/version-v0.5-sidebars.json similarity index 80% rename from operating_versioned_sidebars/version-v0.5-sidebars.json rename to kuperator_versioned_sidebars/version-v0.5-sidebars.json index 91fbd4d5..f12156e2 100644 --- a/operating_versioned_sidebars/version-v0.5-sidebars.json +++ b/kuperator_versioned_sidebars/version-v0.5-sidebars.json @@ -1,5 +1,5 @@ { - "operating": [ + "kuperator": [ { "type": "autogenerated", "dirName": "." diff --git a/operating_versions.json b/kuperator_versions.json similarity index 100% rename from operating_versions.json rename to kuperator_versions.json diff --git a/sidebars/operating.js b/sidebars/kuperator.js similarity index 100% rename from sidebars/operating.js rename to sidebars/kuperator.js diff --git a/static/img/operating/concepts/podopslifecycle/pod-ops-lifecycle-sequence-diagram.png b/static/img/kuperator/concepts/podopslifecycle/pod-ops-lifecycle-sequence-diagram.png similarity index 100% rename from static/img/operating/concepts/podopslifecycle/pod-ops-lifecycle-sequence-diagram.png rename to static/img/kuperator/concepts/podopslifecycle/pod-ops-lifecycle-sequence-diagram.png diff --git a/static/img/operating/concepts/podopslifecycle/pod-ops-lifecycle.png b/static/img/kuperator/concepts/podopslifecycle/pod-ops-lifecycle.png similarity index 100% rename from static/img/operating/concepts/podopslifecycle/pod-ops-lifecycle.png rename to static/img/kuperator/concepts/podopslifecycle/pod-ops-lifecycle.png diff --git a/static/img/operating/manuals/collaset/operation-delay-seconds.png b/static/img/kuperator/manuals/collaset/operation-delay-seconds.png similarity index 100% rename from static/img/operating/manuals/collaset/operation-delay-seconds.png rename to static/img/kuperator/manuals/collaset/operation-delay-seconds.png diff --git a/static/kueperator/index.html b/static/kuperator/index.html similarity index 100% rename from static/kueperator/index.html rename to static/kuperator/index.html