From 785b04fa24c262885e851dafcd7e86f849ed2bb3 Mon Sep 17 00:00:00 2001 From: Amine Date: Fri, 8 Nov 2024 16:54:24 -0800 Subject: [PATCH] Update docs to use KRO instead --- ...ev-Interface.png => KRO-Dev-Interface.png} | Bin ...Symphony-Instance.png => KRO-Instance.png} | Bin ...latform-Team.png => KRO-Platform-Team.png} | Bin website/docs/api/out.md | 168 +++++------- .../docs/docs/concepts/00-resource-groups.md | 82 +++--- .../docs/docs/concepts/10-simple-schema.md | 91 ++++--- website/docs/docs/concepts/15-claims.md | 62 ++--- website/docs/docs/concepts/20-collections.md | 42 +-- website/docs/docs/concepts/_category_.json | 2 +- .../docs/getting-started/01-Installation.md | 62 ++--- .../02-deploy-a-resource-group.md | 151 +++++------ website/docs/docs/overview.md | 52 ++-- website/docs/examples/deploymentdbinstance.md | 56 ++-- website/docs/examples/deploymentservice.md | 72 ++--- website/docs/examples/ekscluster.md | 250 +++++++++--------- website/docs/examples/empty.md | 6 +- website/docusaurus.config.ts | 33 ++- website/package-lock.json | 4 +- website/package.json | 4 +- .../src/components/HomepageFeatures/index.tsx | 63 +++-- website/src/pages/index.tsx | 31 ++- 21 files changed, 605 insertions(+), 626 deletions(-) rename images/architecture-diagrams/{Symphony-Dev-Interface.png => KRO-Dev-Interface.png} (100%) rename images/architecture-diagrams/{Symphony-Instance.png => KRO-Instance.png} (100%) rename images/architecture-diagrams/{Symphony-Platform-Team.png => KRO-Platform-Team.png} (100%) diff --git a/images/architecture-diagrams/Symphony-Dev-Interface.png b/images/architecture-diagrams/KRO-Dev-Interface.png similarity index 100% rename from images/architecture-diagrams/Symphony-Dev-Interface.png rename to images/architecture-diagrams/KRO-Dev-Interface.png diff --git a/images/architecture-diagrams/Symphony-Instance.png b/images/architecture-diagrams/KRO-Instance.png similarity index 100% rename from images/architecture-diagrams/Symphony-Instance.png rename to images/architecture-diagrams/KRO-Instance.png diff --git a/images/architecture-diagrams/Symphony-Platform-Team.png b/images/architecture-diagrams/KRO-Platform-Team.png similarity index 100% rename from images/architecture-diagrams/Symphony-Platform-Team.png rename to images/architecture-diagrams/KRO-Platform-Team.png diff --git a/website/docs/api/out.md b/website/docs/api/out.md index d4b7ea60..73fb037d 100644 --- a/website/docs/api/out.md +++ b/website/docs/api/out.md @@ -1,184 +1,138 @@ --- -sidebar_label: 'ResourceGroup API' +sidebar_label: "ResourceGroup API" sidebar_position: 100 --- + # API Reference ## Packages -- [x.symphony.k8s.aws/v1alpha1](#xsymphonyk8sawsv1alpha1) +- [kro.run/v1alpha1](#krorunv1alpha1) -## x.symphony.k8s.aws/v1alpha1 +## kro.run/v1alpha1 Package v1alpha1 contains API Schema definitions for the x v1alpha1 API group ### Resource Types + - [ResourceGroup](#resourcegroup) - [ResourceGroupList](#resourcegrouplist) #### Condition - - Condition is the common struct used by all CRDs managed by ACK service -controllers to indicate terminal states of the CR and its backend AWS -service API resource - - +controllers to indicate terminal states of the CR and its backend AWS service +API resource _Appears in:_ -- [ResourceGroupStatus](#resourcegroupstatus) -| Field | Description | Default | Validation | -| --- | --- | --- | --- | -| `type` _[ConditionType](#conditiontype)_ | Type is the type of the Condition | | | -| `status` _[ConditionStatus](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.3/#conditionstatus-v1-core)_ | Status of the condition, one of True, False, Unknown. | | | -| `lastTransitionTime` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.3/#time-v1-meta)_ | Last time the condition transitioned from one status to another. | | | -| `reason` _string_ | The reason for the condition's last transition. | | | -| `message` _string_ | A human readable message indicating details about the transition. | | | -| `observedGeneration` _integer_ | observedGeneration represents the .metadata.generation that the condition was set based upon.
For instance, if .metadata.generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date
with respect to the current state of the instance. | | Minimum: 0
| +- [ResourceGroupStatus](#resourcegroupstatus) +| Field | Description | Default | Validation | +| ------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | ----------------- | +| `type` _[ConditionType](#conditiontype)_ | Type is the type of the Condition | | | +| `status` _[ConditionStatus](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.3/#conditionstatus-v1-core)_ | Status of the condition, one of True, False, Unknown. | | | +| `lastTransitionTime` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.3/#time-v1-meta)_ | Last time the condition transitioned from one status to another. | | | +| `reason` _string_ | The reason for the condition's last transition. | | | +| `message` _string_ | A human readable message indicating details about the transition. | | | +| `observedGeneration` _integer_ | observedGeneration represents the .metadata.generation that the condition was set based upon.
For instance, if .metadata.generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date
with respect to the current state of the instance. | | Minimum: 0
| #### ConditionType _Underlying type:_ _string_ - - - - _Appears in:_ -- [Condition](#condition) - +- [Condition](#condition) #### Definition - - - - - - _Appears in:_ -- [ResourceGroupSpec](#resourcegroupspec) -| Field | Description | Default | Validation | -| --- | --- | --- | --- | -| `spec` _[RawExtension](#rawextension)_ | | | | -| `status` _[RawExtension](#rawextension)_ | | | | -| `types` _[RawExtension](#rawextension)_ | | | | -| `validation` _string array_ | | | | +- [ResourceGroupSpec](#resourcegroupspec) +| Field | Description | Default | Validation | +| ---------------------------------------- | ----------- | ------- | ---------- | +| `spec` _[RawExtension](#rawextension)_ | | | | +| `status` _[RawExtension](#rawextension)_ | | | | +| `types` _[RawExtension](#rawextension)_ | | | | +| `validation` _string array_ | | | | #### Resource - - - - - - _Appears in:_ -- [ResourceGroupSpec](#resourcegroupspec) -| Field | Description | Default | Validation | -| --- | --- | --- | --- | -| `name` _string_ | | | Required: {}
| -| `definition` _[RawExtension](#rawextension)_ | | | Required: {}
| +- [ResourceGroupSpec](#resourcegroupspec) +| Field | Description | Default | Validation | +| -------------------------------------------- | ----------- | ------- | ------------------- | +| `name` _string_ | | | Required: {}
| +| `definition` _[RawExtension](#rawextension)_ | | | Required: {}
| #### ResourceGroup - - ResourceGroup is the Schema for the resourcegroups API - - _Appears in:_ -- [ResourceGroupList](#resourcegrouplist) -| Field | Description | Default | Validation | -| --- | --- | --- | --- | -| `apiVersion` _string_ | `x.symphony.k8s.aws/v1alpha1` | | | -| `kind` _string_ | `ResourceGroup` | | | -| `kind` _string_ | Kind is a string value representing the REST resource this object represents.
Servers may infer this from the endpoint the client submits requests to.
Cannot be updated.
In CamelCase.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds | | | -| `apiVersion` _string_ | APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources | | | -| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.3/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | -| `spec` _[ResourceGroupSpec](#resourcegroupspec)_ | | | | -| `status` _[ResourceGroupStatus](#resourcegroupstatus)_ | | | | +- [ResourceGroupList](#resourcegrouplist) +| Field | Description | Default | Validation | +| ----------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | ---------- | +| `apiVersion` _string_ | `kro.run/v1alpha1` | | | +| `kind` _string_ | `ResourceGroup` | | | +| `kind` _string_ | Kind is a string value representing the REST resource this object represents.
Servers may infer this from the endpoint the client submits requests to.
Cannot be updated.
In CamelCase.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds | | | +| `apiVersion` _string_ | APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.3/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[ResourceGroupSpec](#resourcegroupspec)_ | | | | +| `status` _[ResourceGroupStatus](#resourcegroupstatus)_ | | | | #### ResourceGroupList - - ResourceGroupList contains a list of ResourceGroup - - - - -| Field | Description | Default | Validation | -| --- | --- | --- | --- | -| `apiVersion` _string_ | `x.symphony.k8s.aws/v1alpha1` | | | -| `kind` _string_ | `ResourceGroupList` | | | -| `kind` _string_ | Kind is a string value representing the REST resource this object represents.
Servers may infer this from the endpoint the client submits requests to.
Cannot be updated.
In CamelCase.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds | | | -| `apiVersion` _string_ | APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources | | | -| `metadata` _[ListMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.3/#listmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | -| `items` _[ResourceGroup](#resourcegroup) array_ | | | | - +| Field | Description | Default | Validation | +| ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | ---------- | +| `apiVersion` _string_ | `kro.run/v1alpha1` | | | +| `kind` _string_ | `ResourceGroupList` | | | +| `kind` _string_ | Kind is a string value representing the REST resource this object represents.
Servers may infer this from the endpoint the client submits requests to.
Cannot be updated.
In CamelCase.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds | | | +| `apiVersion` _string_ | APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources | | | +| `metadata` _[ListMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.3/#listmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `items` _[ResourceGroup](#resourcegroup) array_ | | | | #### ResourceGroupSpec - - ResourceGroupSpec defines the desired state of ResourceGroup - - _Appears in:_ -- [ResourceGroup](#resourcegroup) -| Field | Description | Default | Validation | -| --- | --- | --- | --- | -| `kind` _string_ | | | Required: {}
| -| `apiVersion` _string_ | | | Required: {}
| -| `definition` _[Definition](#definition)_ | | | Required: {}
| -| `resources` _[Resource](#resource) array_ | | | Optional: {}
| +- [ResourceGroup](#resourcegroup) +| Field | Description | Default | Validation | +| ----------------------------------------- | ----------- | ------- | ------------------- | +| `kind` _string_ | | | Required: {}
| +| `apiVersion` _string_ | | | Required: {}
| +| `definition` _[Definition](#definition)_ | | | Required: {}
| +| `resources` _[Resource](#resource) array_ | | | Optional: {}
| #### ResourceGroupState _Underlying type:_ _string_ - - - - _Appears in:_ -- [ResourceGroupStatus](#resourcegroupstatus) - +- [ResourceGroupStatus](#resourcegroupstatus) #### ResourceGroupStatus - - ResourceGroupStatus defines the observed state of ResourceGroup - - _Appears in:_ -- [ResourceGroup](#resourcegroup) - -| Field | Description | Default | Validation | -| --- | --- | --- | --- | -| `state` _[ResourceGroupState](#resourcegroupstate)_ | State is the state of the resourcegroup | | | -| `topologicalOrder` _string array_ | TopologicalOrder is the topological order of the resourcegroup graph | | | -| `conditions` _[Condition](#condition) array_ | Conditions represent the latest available observations of an object's state | | | - - +- [ResourceGroup](#resourcegroup) +| Field | Description | Default | Validation | +| --------------------------------------------------- | --------------------------------------------------------------------------- | ------- | ---------- | +| `state` _[ResourceGroupState](#resourcegroupstate)_ | State is the state of the resourcegroup | | | +| `topologicalOrder` _string array_ | TopologicalOrder is the topological order of the resourcegroup graph | | | +| `conditions` _[Condition](#condition) array_ | Conditions represent the latest available observations of an object's state | | | diff --git a/website/docs/docs/concepts/00-resource-groups.md b/website/docs/docs/concepts/00-resource-groups.md index aa306535..e26473f5 100644 --- a/website/docs/docs/concepts/00-resource-groups.md +++ b/website/docs/docs/concepts/00-resource-groups.md @@ -4,14 +4,15 @@ sidebar_position: 1 # 1. ResourceGroups -**ResourceGroups** are the fundamental building blocks in Symphony. They -provide a way to define, organize, and manage sets of related Kubernetes -resources as a single, reusable unit. +**ResourceGroups** are the fundamental building blocks in KRO. They provide a +way to define, organize, and manage sets of related Kubernetes resources as a +single, reusable unit. ## What is a **ResourceGroup**? A **ResourceGroup** is a custom resource that serves as a blueprint for creating and managing a collection of Kubernetes resources. It allows you to: + - Define multiple resources in a single, cohesive unit - Establish relationships and dependencies between resources - Create high-level abstractions of complex Kubernetes configurations @@ -20,19 +21,21 @@ and managing a collection of Kubernetes resources. It allows you to: ## Anatomy of a **ResourceGroup** A **ResourceGroup**, like any Kubernetes resource, consists of three main parts: + 1. **Metadata**: Name, namespace, labels, etc. 2. **Spec**: Defines the structure and properties of the ResourceGroup 3. **Status**: Reflects the current state of the ResourceGroup The `spec` section of a ResourceGroup typically includes: + - **Parameters**: Define the customizable aspects of the ResourceGroup - **Resources**: Specify the Kubernetes resources to be created - The **kind** and **apiVersion** fields within the spec define the CRD that - will be generated for this ResourceGroup. - Here's a simple example of a ResourceGroup: + will be generated for this ResourceGroup. Here's a simple example of a + ResourceGroup: ```yaml text title="simple-web-app.yaml" -apiVersion: symphony.k8s.aws/v1 +apiVersion: kro.run/v1 kind: ResourceGroup metadata: name: simple-web-app @@ -77,59 +80,58 @@ spec: targetPort: 80 ``` -In this example, the **ResourceGroup** defines a simple web application with -a Deployment and a Service. The appName, image, and replicas are -parameters that can be set when instantiating this ResourceGroup. +In this example, the **ResourceGroup** defines a simple web application with a +Deployment and a Service. The appName, image, and replicas are parameters that +can be set when instantiating this ResourceGroup. ## **ResourceGroup** Processing -When a **ResourceGroup** is submitted to the Kubernetes API server, the -Symphony controller processes it as follows: +When a **ResourceGroup** is submitted to the Kubernetes API server, the KRO +controller processes it as follows: + +1. **Formal Verification**: The controller performs a comprehensive analysis of + the ResourceGroup definition. This includes: -1. **Formal Verification**: The controller performs a comprehensive analysis - of the ResourceGroup definition. This includes: - **Syntax checking**: Ensuring all fields are correctly formatted. - - **Type checking**: Validating that parameter types match their - definitions. - - **Semantic validation**: Verifying that resource relationships and + - **Type checking**: Validating that parameter types match their definitions. + - **Semantic validation**: Verifying that resource relationships and dependencies are logically sound. - - **Dry-run validation**: Simulating the creation of resources to detect + - **Dry-run validation**: Simulating the creation of resources to detect potential issues. -2. **CRD Generation**: The controller automatically generates a new **Custom - Resource Definition (CRD)** based on the ResourceGroup's specification. - This CRD represents the type for instances of this ResourceGroup. +2. **CRD Generation**: The controller automatically generates a new **Custom + Resource Definition (CRD)** based on the ResourceGroup's specification. This + CRD represents the type for instances of this ResourceGroup. -3. **CRD Registration**: It registers the newly generated CRD with the +3. **CRD Registration**: It registers the newly generated CRD with the Kubernetes API server, making it available for use in the cluster. -4. **Micro-Controller Deployment**: Symphony deploys a dedicated - micro-controller for this ResourceGroup. This micro-controller will - listen for **"claim" events** - instances of the CRD created in step 2. - It will be responsible for managing the **lifecycle of resources** defined - in the ResourceGroup for each claim. +4. **Micro-Controller Deployment**: KRO deploys a dedicated micro-controller for + this ResourceGroup. This micro-controller will listen for **"claim" + events** - instances of the CRD created in step 2. It will be responsible for + managing the **lifecycle of resources** defined in the ResourceGroup for each + claim. -5. **Status Update**: The controller updates the status of the ResourceGroup - to reflect that the corresponding CRD has been created and registered. +5. **Status Update**: The controller updates the status of the ResourceGroup to + reflect that the corresponding CRD has been created and registered. -For example, given our `simple-web-app` ResourceGroup, the controller -would create and register a CRD named `SimpleWebApps` (plural form of the -ResourceGroup name). This CRD defines the structure for creating instances -of the web application with customizable parameters. The deployed -micro-controller would then manage all **SimpleWebApps instances**, creating -and managing the associated **Deployments** and **Services** as defined in the -ResourceGroup. +For example, given our `simple-web-app` ResourceGroup, the controller would +create and register a CRD named `SimpleWebApps` (plural form of the +ResourceGroup name). This CRD defines the structure for creating instances of +the web application with customizable parameters. The deployed micro-controller +would then manage all **SimpleWebApps instances**, creating and managing the +associated **Deployments** and **Services** as defined in the ResourceGroup. -The Symphony controller continues to monitor the **ResourceGroup** for any +The **KRO** controller continues to monitor the **ResourceGroup** for any changes, updating the corresponding CRD and micro-controller as necessary. ## **ResourceGroup** Claim Example -After the **ResourceGroup** is processed, users can create instances of it. Here's -an example of how a claim for the `SimpleWebApp` might look: +After the **ResourceGroup** is processed, users can create instances of it. +Here's an example of how a claim for the `SimpleWebApp` might look: ```yaml title="my-web-app-claim.yaml" -apiVersion: symphony.k8s.aws/v1alpha1 +apiVersion: kro.run/v1alpha1 kind: SimpleWebApp metadata: name: my-web-app @@ -140,4 +142,4 @@ spec: ``` In the next section, we'll explore the `parameters` and `resources` sections of -a **ResourceGroup** in more detail. \ No newline at end of file +a **ResourceGroup** in more detail. diff --git a/website/docs/docs/concepts/10-simple-schema.md b/website/docs/docs/concepts/10-simple-schema.md index 14e86523..97e1c565 100644 --- a/website/docs/docs/concepts/10-simple-schema.md +++ b/website/docs/docs/concepts/10-simple-schema.md @@ -4,14 +4,14 @@ sidebar_position: 2 # 2. Simple Schema -Symphony's Simple Schema provides a powerful yet intuitive way to define the structure -of your ResourceGroup. Here is comprehensive example: +KRO's Simple Schema provides a powerful yet intuitive way to define the +structure of your ResourceGroup. Here is comprehensive example: ```yaml -apiVersion: symphony.k8s.aws/v1alpha1 +apiVersion: kro.run/v1alpha1 kind: ResourceGroup metadata: - name: webapplication.symphony.k8s.aws + name: web-application spec: apiVersion: v1alpha1 kind: WebApplication @@ -40,6 +40,7 @@ spec: ### 1. Spec Field Definition #### Basic Types + - `string`: Basic string type - `integer`: Whole number - `boolean`: True/False value @@ -53,11 +54,11 @@ age: integer #### Structure types -Structure types or object types are defined by specifying the fields within the object. The fields -can be of basic types or other structure types. +Structure types or object types are defined by specifying the fields within the +object. The fields can be of basic types or other structure types. -for example to define a structure type for a person with name and age fields, you can define it as -follows: +for example to define a structure type for a person with name and age fields, +you can define it as follows: ```yaml person: @@ -68,34 +69,40 @@ person: #### Map Types - Arrays: Denoted by `[]`, e.g., `'[]string'` -- Maps: Denoted by `map[keyType]valueType`, e.g., `'map[string]string'` and `'map[string]Person'` +- Maps: Denoted by `map[keyType]valueType`, e.g., `'map[string]string'` and + `'map[string]Person'` ### 2. Validation and Documentation Markers -In addition to the type, fields can also have markers for validation, documentation and -other purposes that are OpenAPISchema compatible. +In addition to the type, fields can also have markers for validation, +documentation and other purposes that are OpenAPISchema compatible. -For example to define a field that is required, has a default value and a description, you can -define it as follows: +For example to define a field that is required, has a default value and a +description, you can define it as follows: ```yaml person: - name: string | required=true default="Kylian Mbappé" description="Name of the person" + name: + string | required=true default="Kylian Mbappé" description="Name of the + person" ``` Currently supported markers include: + - `required=true`: Field must be provided - `default=value`: Default value if not provided - `description="..."`: Provides documentation for the field - `enum="value1,value2,..."`: Restricts to a set of values **NOT IMPLEMENTED** -- `minimum=value` and `maximum=value`: For numeric constraints **NOT IMPLEMENTED** +- `minimum=value` and `maximum=value`: For numeric constraints **NOT + IMPLEMENTED** ### 3. Custom Types Definition -Custom types are defined in the `customTypes` section, allowing for reusable complex -structures. They can be referenced by name in the spec or status fields. +Custom types are defined in the `customTypes` section, allowing for reusable +complex structures. They can be referenced by name in the spec or status fields. Example: + ```yaml customTypes: ConfigType: @@ -107,21 +114,21 @@ spec: ### 4. Status Field Definition -Status fields are defined similarly to spec fields and can include validation and documentation -markers. However on top of that, status fields can also include value markers: +Status fields are defined similarly to spec fields and can include validation +and documentation markers. However on top of that, status fields can also +include value markers: #### Value Marker **NOT IMPLEMENTED** -- `value="${resource.status.field}"`: Specifies that this field's value should be dynamically - obtained from another resource. The value is a CEL expression that is validated at ResourceGroup - processing time and evaluated at runtime. +- `value="${resource.status.field}"`: Specifies that this field's value should + be dynamically obtained from another resource. The value is a CEL expression + that is validated at ResourceGroup processing time and evaluated at runtime. -:::tip - Note that the value marker is a symphony extension to the OpenAPISchema and is not part of the - official OpenAPISchema specification. -::: +:::tip Note that the value marker is a KRO extension to the OpenAPISchema and is +not part of the official OpenAPISchema specification. ::: Example: + ```yaml status: url: string | value="${service.status.loadBalancer.ingress[0].hostname}" @@ -129,26 +136,23 @@ status: ## Default status fields -Symphony automatically injects two common fields into the status of all claims -generated from **ResourceGroups**: `conditions` and `state`. These fields provide -essential information about the current status of the claim and its associated -resources. - -:::tip -`conditions` and `state` are reserved words in the status -section. If a user defines these fields in their **ResourceGroup**'s status schema, -Symphony will override them with its own values. -::: +**KRO** automatically injects two common fields into the status of all claims +generated from **ResourceGroups**: `conditions` and `state`. These fields +provide essential information about the current status of the claim and its +associated resources. +:::tip `conditions` and `state` are reserved words in the status section. If a +user defines these fields in their **ResourceGroup**'s status schema, KRO will +override them with its own values. ::: ### 1. Conditions The `conditions` field is an array of condition objects, each representing a -specific aspect of the claim's state. Symphony automatically manages this field. +specific aspect of the claim's state. KRO automatically manages this field. ```yaml status: - conditions: '[]condition' + conditions: "[]condition" customTypes: condition: type: string @@ -159,9 +163,12 @@ customTypes: ``` Common condition types include: + - `Ready`: Indicates whether the claim is fully reconciled and operational. -- `Progressing`: Shows if the claim is in the process of reaching the desired state. -- `Degraded`: Signals that the claim is operational but not functioning optimally. +- `Progressing`: Shows if the claim is in the process of reaching the desired + state. +- `Degraded`: Signals that the claim is operational but not functioning + optimally. - `Error`: Indicates that an error has occurred during reconciliation. ### 2. State @@ -174,5 +181,5 @@ status: ``` > These default status fields are automatically added to every claim's status, -providing a consistent way to check the health and state of resources across -different **ResourceGroups**. \ No newline at end of file +> providing a consistent way to check the health and state of resources across +> different **ResourceGroups**. diff --git a/website/docs/docs/concepts/15-claims.md b/website/docs/docs/concepts/15-claims.md index 50b137c3..0ffce9c1 100644 --- a/website/docs/docs/concepts/15-claims.md +++ b/website/docs/docs/concepts/15-claims.md @@ -4,13 +4,14 @@ sidebar_position: 15 # 3. Claims -Claims are a fundamental concept in Symphony that represent instances of -ResourceGroups. They define the desired state of a set of resources, which -Symphony continuously works to maintain. +Claims are a fundamental concept in **KRO** that represent instances of +ResourceGroups. They define the desired state of a set of resources, which KRO +continuously works to maintain. ## What is a Claim? A Claim is a Kubernetes custom resource that: + - References a specific ResourceGroup - Provides values for the parameters defined in the ResourceGroup - Represents the desired state of a set of Kubernetes resources @@ -20,7 +21,7 @@ A Claim is a Kubernetes custom resource that: Here's an example of a Claim for a `WebApplication` ResourceGroup: ```yaml -apiVersion: symphony.k8s.aws/v1alpha1 +apiVersion: kro.run/v1alpha1 kind: WebApplication metadata: name: my-web-app @@ -36,26 +37,24 @@ spec: LOG_LEVEL: debug ``` -:::tip -The spec fields of a Claim correspond to the parameters defined in the -ResourceGroup. -::: +:::tip The spec fields of a Claim correspond to the parameters defined in the +ResourceGroup. ::: ## The reconciliation loop -Symphony manages Claims through a continuous reconciliation process: +KRO manages Claims through a continuous reconciliation process: -- **Desired state detection**: Symphony observes the Claim, which represents - the desired state of resources. -- **Current state assessment**: Symphony talks to the api-server and checks - the current state of resources in the cluster related to the Claim. +- **Desired state detection**: KRO observes the Claim, which represents the + desired state of resources. +- **Current state assessment**: KRO talks to the api-server and checks the + current state of resources in the cluster related to the Claim. - **Difference identification**: Any differences between the desired state (Claim) and the current state are identified. -- **State Reconciliation**: Symphony takes necessary actions to align the - current state with the desired state. This may involve creating, updating, - or deleting resources as needed. -- **Status Updates**: The Claim's status is updated to reflect the current - state of reconciliation and any issues encountered. +- **State Reconciliation**: KRO takes necessary actions to align the current + state with the desired state. This may involve creating, updating, or deleting + resources as needed. +- **Status Updates**: The Claim's status is updated to reflect the current state + of reconciliation and any issues encountered. - **Continuous Loop**: This process repeats regularly, ensuring the cluster state always converges towards the desired state defined in the Claim. @@ -73,34 +72,35 @@ Symphony manages Claims through a continuous reconciliation process: :::tip Best Practices - Treat claims as declarative definitions of your application's desired state. -Use version control for your Claims to track changes over time. + Use version control for your Claims to track changes over time. - Leverage labels and annotations in Claims for organization and filtering. - Regularly review Claims to ensure they reflect current requirements. -- Use Symphony's dry-run feature to preview reconciliation actions before - applying changes to Claims. +- Use KRO's dry-run feature to preview reconciliation actions before applying + changes to Claims. - Monitor Claim statuses to understand the current state of your applications. -::: + ::: ## Common Status Fields -Symphony automatically injects two common fields into the status of all claims: +KRO automatically injects two common fields into the status of all claims: **Conditions** and **State**. These fields provide crucial information about the current status of the claim and its associated resources. ### 1. Conditions -Conditions are a standard Kubernetes concept that Symphony leverages to provide +Conditions are a standard Kubernetes concept that KRO leverages to provide detailed status information. Each condition represents a specific aspect of the claim's state. Common conditions include: - **Ready**: Indicates whether the claim is fully reconciled and operational. -- **Progressing**: Shows if the claim is in the process of reaching the desired +- **Progressing**: Shows if the claim is in the process of reaching the desired state. -- **Degraded**: Signals that the claim is operational but not functioning +- **Degraded**: Signals that the claim is operational but not functioning optimally. - **Error**: Indicates that an error has occurred during reconciliation. Each condition typically includes the following properties: + - **Type**: The name of the condition (e.g., "Ready"). - **Status**: Either "True", "False", or "Unknown". - **LastTransitionTime**: When the condition last changed. @@ -108,6 +108,7 @@ Each condition typically includes the following properties: - **Message**: A human-readable description of the condition. Example: + ```yaml status: conditions: @@ -120,10 +121,10 @@ status: ### 2. State -The State field provides a high-level summary of the claim's current status. -It is typically one of the following values: +The State field provides a high-level summary of the claim's current status. It +is typically one of the following values: -- **Pending**: The claim is being processed, but resources are not yet fully +- **Pending**: The claim is being processed, but resources are not yet fully created or configured. - **Running**: All resources are created and the claim is operational. - **Failed**: An error occurred and the claim could not be fully reconciled. @@ -132,6 +133,7 @@ It is typically one of the following values: - **Unknown**: The claim's status cannot be determined. Example: + ```yaml status: state: Running @@ -140,4 +142,4 @@ status: These common status fields provide users with a consistent and informative way to check the health and state of their claims across different ResourceGroups. They are essential for monitoring, troubleshooting, and automating operations -based on the status of Symphony-managed resources. +based on the status of KRO-managed resources. diff --git a/website/docs/docs/concepts/20-collections.md b/website/docs/docs/concepts/20-collections.md index 9e43b915..4d2a176a 100644 --- a/website/docs/docs/concepts/20-collections.md +++ b/website/docs/docs/concepts/20-collections.md @@ -4,14 +4,14 @@ sidebar_position: 20 # 4. Collections -Collections in Symphony provide a powerful way to manage groups of similar -resources within a **ResourceGroup**. They allow for dynamic creation and -management of multiple instances of a resource type based on user input. +Collections in KRO provide a powerful way to manage groups of similar resources +within a **ResourceGroup**. They allow for dynamic creation and management of +multiple instances of a resource type based on user input. ## What are Collections? -A collection is a special field in a **ResourceGroup** that defines a template for -creating multiple similar resources. Key features of collections include: +A collection is a special field in a **ResourceGroup** that defines a template +for creating multiple similar resources. Key features of collections include: - Dynamic creation of resources based on user input - Consistent structure across multiple resource instances @@ -22,10 +22,10 @@ creating multiple similar resources. Key features of collections include: Here's an example of how to define a collection in a ResourceGroup: ```yaml -apiVersion: symphony.k8s.aws/v1alpha1 +apiVersion: kro.run/v1alpha1 kind: ResourceGroup metadata: - name: ReplicaSet.x.symphony.k8s.aws + name: replica-set spec: kind: ReplicaSet apiVersion: v1alpha1 @@ -48,8 +48,8 @@ spec: image: nginx:latest ``` -In this example, `nodes` is a collection that will create multiple Pod -resources based on the `podCount` parameter. +In this example, `nodes` is a collection that will create multiple Pod resources +based on the `podCount` parameter. ## Key Concepts @@ -64,7 +64,7 @@ resources based on the `podCount` parameter. When creating a claim, users can specify the count for the collection: ```yaml -apiVersion: symphony.k8s.aws/v1alpha1 +apiVersion: kro.run/v1alpha1 kind: ReplicaSet metadata: name: my-db-cluster @@ -79,17 +79,19 @@ This claim will result in the creation of three Postgres Pods named ## Deployment Strategy While defining collections is straightforward, it's essential to consider the -deployment strategy for managing multiple resources. Symphony provides -flexibility in managing collections, allowing users to define how resources are -created, updated, and deleted based on the desired state. +deployment strategy for managing multiple resources. KRO provides flexibility in +managing collections, allowing users to define how resources are created, +updated, and deleted based on the desired state. -Symphony provide two strategies for managing collections: -- **RollingUpdate**: Creates, updates and deletes resources in an incremental manner, - ensuring that only one resource is updated at a time. -- **ParallelUpdate**: Creates, updates and deletes resources in parallel, allowing - for faster deployment of multiple resources. +KRO provide two strategies for managing collections: -For examples you can add the following to the `spec` section of the `ResourceGroup`: +- **RollingUpdate**: Creates, updates and deletes resources in an incremental + manner, ensuring that only one resource is updated at a time. +- **ParallelUpdate**: Creates, updates and deletes resources in parallel, + allowing for faster deployment of multiple resources. + +For examples you can add the following to the `spec` section of the +`ResourceGroup`: ```yaml spec: @@ -113,4 +115,4 @@ spec: containers: - name: db image: nginx:latest -``` \ No newline at end of file +``` diff --git a/website/docs/docs/concepts/_category_.json b/website/docs/docs/concepts/_category_.json index 4d2633da..8727ac2d 100644 --- a/website/docs/docs/concepts/_category_.json +++ b/website/docs/docs/concepts/_category_.json @@ -3,6 +3,6 @@ "position": 40, "link": { "type": "generated-index", - "description": "Learn about the core concepts of Symphony" + "description": "Learn about the core concepts of KRO" } } diff --git a/website/docs/docs/getting-started/01-Installation.md b/website/docs/docs/getting-started/01-Installation.md index 6550e1f0..23bbff41 100644 --- a/website/docs/docs/getting-started/01-Installation.md +++ b/website/docs/docs/getting-started/01-Installation.md @@ -2,10 +2,10 @@ sidebar_position: 1 --- -# Installing Symphony +# Installing KRO -This guide walks you through the process of installing Symphony on your -Kubernetes cluster using Helm. +This guide walks you through the process of installing KRO on your Kubernetes +cluster using Helm. ## Prerequisites @@ -16,32 +16,32 @@ Before you begin, ensure you have the following: ## Installation Steps -:::info[**Alpha Stage**] Symphony is currently in alpha stage. While the images -are publicly available, please note that the software is still under active +:::info[**Alpha Stage**] KRO is currently in alpha stage. While the images are +publicly available, please note that the software is still under active development and APIs may change. ::: -### Install Symphony using Helm +### Install KRO using Helm -Once authenticated, install Symphony using the Helm chart: +Once authenticated, install KRO using the Helm chart: ```sh # Fetch the latest release version from GitHub -export SYMPHONY_VERSION=$(curl -s \ - https://api.github.com/repos/awslabs/private-symphony/releases/latest | \ +export KRO_VERSION=$(curl -s \ + https://api.github.com/repos/awslabs/kro/releases/latest | \ grep '"tag_name":' | \ sed -E 's/.*"([^"]+)".*/\1/' \ ) -# Install Symphony -helm install symphony oci://public.ecr.aws/symphony/symphony \ - --namespace symphony \ +# Install KRO using Helm +helm install kro oci://public.ecr.aws/kro/kro \ + --namespace kro \ --create-namespace \ - --version=${SYMPHONY_VERSION} + --version=${KRO_VERSION} ``` ## Verifying the Installation -After running the installation command, verify that Symphony has been installed +After running the installation command, verify that Kro has been installed correctly: 1. Check the Helm release: @@ -50,40 +50,40 @@ correctly: helm list ``` - You should see the "symphony" release listed. + You should see the "kro" release listed. -2. Check the Symphony pods: +2. Check the KRO pods: ```sh - kubectl get pods + kubectl get pods -n kro ``` - You should see Symphony-related pods running. + You should see kro-related pods running. -## Upgrading Symphony +## Upgrading KRO -To upgrade to a newer version of Symphony, use the Helm upgrade command: +To upgrade to a newer version of KRO, use the Helm upgrade command: ```bash # Replace `` with the version you want to upgrade to. -export SYMPHONY_VERSION= +export KRO_VERSION= # Upgrade the controller -helm upgrade symphony oci://public.ecr.aws/symphony/symphony \ - --namespace symphony \ - --version=${SYMPHONY_VERSION} +helm upgrade kro oci://public.ecr.aws/kro/kro \ + --namespace kro \ + --version=${KRO_VERSION} ``` :::info Helm does not support updating CRDs, so you may need to manually update -or remove symphony related CRDs. For more information, refer to the Helm +or remove kro related CRDs. For more information, refer to the Helm documentation. ::: -## Uninstalling Symphony +## Uninstalling KRO -To uninstall Symphony, use the following command: +To uninstall KRO, use the following command: ```bash -helm uninstall symphony +helm uninstall kro -n kro ``` -Keep in mind that this command will remove all Symphony resources from your -cluster, except for the ResourceGroup CRD and any other custom resources you may -have created. +Keep in mind that this command will remove all KRO resources from your cluster, +except for the ResourceGroup CRD and any other custom resources you may have +created. diff --git a/website/docs/docs/getting-started/02-deploy-a-resource-group.md b/website/docs/docs/getting-started/02-deploy-a-resource-group.md index a0e55175..5af38fa8 100644 --- a/website/docs/docs/getting-started/02-deploy-a-resource-group.md +++ b/website/docs/docs/getting-started/02-deploy-a-resource-group.md @@ -4,24 +4,25 @@ sidebar_position: 2 # Deploy a Resource Group -ResourceGroups are the core building blocks of Symphony. They define the -structure of your application and the resources it requires. In this guide, -you'll learn how to deploy a ResourceGroup using Symphony. +ResourceGroups are the core building blocks of KRO. They define the structure of +your application and the resources it requires. In this guide, you'll learn how +to deploy a ResourceGroup using KRO. ## Prerequisites Before you begin, ensure you have the following: -- Installed Symphony on your Kubernetes cluster + +- Installed KRO on your Kubernetes cluster - A ResourceGroup manifest file -For this examole, we'll use a simple ResourceGroup that defines a Deployment -and a Service. Here's an example of a `ResourceGroup` manifest file: +For this examole, we'll use a simple ResourceGroup that defines a Deployment and +a Service. Here's an example of a `ResourceGroup` manifest file: ```yaml title="deploymentservice-rg.yaml" -apiVersion: x.symphony.k8s.aws/v1alpha1 +apiVersion: kro.run/v1alpha1 kind: ResourceGroup metadata: - name: deploymentservice.x.symphony.k8s.aws + name: deployment-service spec: apiVersion: v1alpha1 kind: DeploymentService @@ -29,40 +30,40 @@ spec: spec: name: string resources: - - name: deployment - definition: - apiVersion: apps/v1 - kind: Deployment - metadata: - name: ${spec.name} - spec: - replicas: 1 - selector: - matchLabels: - app: deployment - template: - metadata: - labels: + - name: deployment + definition: + apiVersion: apps/v1 + kind: Deployment + metadata: + name: ${spec.name} + spec: + replicas: 1 + selector: + matchLabels: app: deployment - spec: - containers: - - name: ${spec.name}-deployment - image: nginx - ports: - - containerPort: 80 - - name: service - definition: - apiVersion: v1 - kind: Service - metadata: - name: ${spec.name} - spec: - selector: - app: deployment - ports: - - protocol: TCP - port: 80 - targetPort: 80 + template: + metadata: + labels: + app: deployment + spec: + containers: + - name: ${spec.name}-deployment + image: nginx + ports: + - containerPort: 80 + - name: service + definition: + apiVersion: v1 + kind: Service + metadata: + name: ${spec.name} + spec: + selector: + app: deployment + ports: + - protocol: TCP + port: 80 + targetPort: 80 ``` ## Steps @@ -71,40 +72,40 @@ spec: ResourceGroup definition. You can use the example above as a template. 2. **Deploy the ResourceGroup**: Use the `kubectl` command to deploy the - ResourceGroup to your Kubernetes cluster: - - ```bash - kubectl apply -f deploymentservice-rg.yaml - ``` + ResourceGroup to your Kubernetes cluster: + + ```bash + kubectl apply -f deploymentservice-rg.yaml + ``` 3. **Verify the resources**: Check the status of the resources created by the - ResourceGroup using the `kubectl` command: - - ```bash - kubectl get rg - ``` - - You should see something like this: - - ```bash - NAME APIVERSION KIND STATE AGE - deploymentservice.x.symphony.k8s.aws v1alpha1 DeploymentService ACTIVE 16m - ``` - -4. **Install a resource group claim**: Create a claim for the resource group - you just deployed. Claims are used to define the desired state of the - resources in the ResourceGroup. - - Here's an example of a Claim for the `EKSCluster` ResourceGroup: - - ```yaml - apiVersion: x.symphony.k8s.aws/v1alpha1 - kind: DeploymentService - metadata: - name: my-deployment-and-service - spec: - name: app1 - ``` + ResourceGroup using the `kubectl` command: + + ```bash + kubectl get rg + ``` + + You should see something like this: + + ```bash + NAME APIVERSION KIND STATE AGE + deployment-service v1alpha1 DeploymentService ACTIVE 16m + ``` + +4. **Install a resource group claim**: Create a claim for the resource group you + just deployed. Claims are used to define the desired state of the resources + in the ResourceGroup. + + Here's an example of a Claim for the `EKSCluster` ResourceGroup: + + ```yaml + apiVersion: kro.run/v1alpha1 + kind: DeploymentService + metadata: + name: my-deployment-and-service + spec: + name: app1 + ``` - The spec fields of a Claim correspond to the parameters defined in the - ResourceGroup. \ No newline at end of file + The spec fields of a Claim correspond to the parameters defined in the + ResourceGroup. diff --git a/website/docs/docs/overview.md b/website/docs/docs/overview.md index 149a0468..fad83340 100644 --- a/website/docs/docs/overview.md +++ b/website/docs/docs/overview.md @@ -2,18 +2,18 @@ sidebar_position: 1 --- -# What is Symphony? +# What is KRO? -**Symphony** is an open-source project that allows you to define custom -**Kubernetes APIs** using straightforward configuration. With Symphony, you can -easily configure new custom APIs that create a group of Kubernetes objects and -the logical operations between them. Symphony automatically calculates the order -in which objects should be created. You can pass values from one object to -another, set default values for fields in the API specification, and incorporate -conditionals into your custom API definitions. End users can easily call these -custom APIs to create grouped resources. +**KRO** (Kube Resource Orchesrtator) is an open-source project that allows you +to define custom **Kubernetes APIs** using straightforward configuration. With +KRO, you can easily configure new custom APIs that create a group of Kubernetes +objects and the logical operations between them. KRO automatically calculates +the order in which objects should be created. You can pass values from one +object to another, set default values for fields in the API specification, and +incorporate conditionals into your custom API definitions. End users can easily +call these custom APIs to create grouped resources. -# How does Symphony work? +# How does KRO work? ### Developer interface @@ -29,12 +29,12 @@ creates resources such as the **Deployment**, **Ingress**, **ServiceAccount**, Developers to easily manage and deploy their applications in a standardized and streamlined manner. -![End user interface - Custom API](../../../images/architecture-diagrams/Symphony-Dev-Interface.png) +![End user interface - Custom API](../../../images/architecture-diagrams/Kro-Dev-Interface.png) _Fugure 1: End user interface - Custom API_ ### ResourceGroup -When you install **Symphony** in your cluster, it installs a Custom Resource +When you install **Kro** in your cluster, it installs a Custom Resource Definition (CRD) called **ResourceGroup (RG)**. The **Platform**, **Security**, and **Compliance** teams, can collaborate to create custom APIs by defining Custom Resources for the ResourceGroup CRD. @@ -47,7 +47,7 @@ longer need to directly manage the underlying infrastructure complexities, as the custom API handles the deployment and configuration of the required resources. -![Platform Team Interface](../../../images/architecture-diagrams/Symphony-Platform-Team.png) +![Platform Team Interface](../../../images/architecture-diagrams/Kro-Platform-Team.png) _Fugure 2: ResourceGroup (RG) - Platform Team Interface_ ### ResourceGroup Instance @@ -61,14 +61,14 @@ keep their service internal to the cluster. This flexibility allows each development team to customize their application stack based on their specific requirements. -![ResourceGroup Instance](../../../images/architecture-diagrams/Symphony-Instance.png) +![ResourceGroup Instance](../../../images/architecture-diagrams/Kro-Instance.png) _Fugure 3: ResourceGroup Instance (RGI)_ -# Why Symphony? +# Why KRO? ### Manage any group of resources as one unit -Using **Symphony**, the **Platform Team** can enable Developer teams to quickly +Using **KRO**, the **Platform Team** can enable Developer teams to quickly deploy and manage applications and their dependencies as one unit, handling the entire lifecycle from deployment to maintenance. The new APIs integrate seamlessly with developers' existing CD tools, preserving familiar processes and @@ -77,12 +77,12 @@ interfaces to simplify adoption. ### Collaborate Transform **Kubernetes** into your unified platform configuration framework -using **Symphony**. Platform, Compliance, and Security teams work together to -develop APIs that standardize and streamline configurations, making it easier -for Developer teams to adopt secure, compliant practices. This collaboration -lets you build your organizational standards directly into the APIs, ensuring -every application deployment aligns with security and compliance requirements -without adding complexity for developers. +using **KRO**. Platform, Compliance, and Security teams work together to develop +APIs that standardize and streamline configurations, making it easier for +Developer teams to adopt secure, compliant practices. This collaboration lets +you build your organizational standards directly into the APIs, ensuring every +application deployment aligns with security and compliance requirements without +adding complexity for developers. ### Standardize @@ -94,8 +94,8 @@ achieving consistency across deployment environments. We welcome questions, suggestions, and contributions from the community! To get involved, check out our -[contributing guide](https://github.com/awslabs/private-symphony/blob/main/CONTRIBUTING.md). +[contributing guide](https://github.com/awslabs/kro/blob/main/CONTRIBUTING.md). For bugs or feature requests, feel free to -[submit an issue](https://github.com/awslabs/private-symphony/issues). You’re -also invited to join our -[community meeting](https://github.com/awslabs/private-symphony?tab=readme-ov-file#symphony). +[submit an issue](https://github.com/awslabs/kro/issues). You’re also invited to +join our +[community meeting](https://github.com/awslabs/kro?tab=readme-ov-file#kro). diff --git a/website/docs/examples/deploymentdbinstance.md b/website/docs/examples/deploymentdbinstance.md index 8a6bdb27..9a8bf359 100644 --- a/website/docs/examples/deploymentdbinstance.md +++ b/website/docs/examples/deploymentdbinstance.md @@ -5,10 +5,10 @@ sidebar_position: 20 # DeploymentDBInstance ```yaml title="deploymentdbinstance-rg.yaml" -apiVersion: x.symphony.k8s/v1alpha1 +apiVersion: kro.run/v1alpha1 kind: ResourceGroup metadata: - name: deploymentandawspostgres.x.symphony.k8s + name: deploymentandawspostgres spec: apiVersion: v1alpha1 kind: DeploymentAndAWSPostgres @@ -22,30 +22,30 @@ spec: # Resources resources: - - name: dbinstance - definition: - apiVersion: rds.saervices.k8s.aws/v1alpha1 - kind: DBInstance - metadata: - name: ${spec.applicationName}-dbinstance - spec: - # need to specify the required fields (e.g masterUsername, masterPassword) - engine: postgres - dbInstanceIdentifier: ${spec.applicationName}-dbinstance - allocatedStorage: 20 - dbInstanceClass: db.t3.micro + - name: dbinstance + definition: + apiVersion: rds.saervices.k8s.aws/v1alpha1 + kind: DBInstance + metadata: + name: ${spec.applicationName}-dbinstance + spec: + # need to specify the required fields (e.g masterUsername, masterPassword) + engine: postgres + dbInstanceIdentifier: ${spec.applicationName}-dbinstance + allocatedStorage: 20 + dbInstanceClass: db.t3.micro - - name: pod - definition: - apiVersion: v1 - kind: Pod - metadata: - name: ${spec.applicationName}-pod - spec: - containers: - - name: container1 - image: ${spec.image} - env: - - name: POSTGRESS_ENDPOINT - value: ${dbinstance.status.endpoint.address} -``` \ No newline at end of file + - name: pod + definition: + apiVersion: v1 + kind: Pod + metadata: + name: ${spec.applicationName}-pod + spec: + containers: + - name: container1 + image: ${spec.image} + env: + - name: POSTGRESS_ENDPOINT + value: ${dbinstance.status.endpoint.address} +``` diff --git a/website/docs/examples/deploymentservice.md b/website/docs/examples/deploymentservice.md index 3c14e4b7..0bb4edc4 100644 --- a/website/docs/examples/deploymentservice.md +++ b/website/docs/examples/deploymentservice.md @@ -5,10 +5,10 @@ sidebar_position: 1 # DeploymentService ```yaml title="deploymentservice-rg.yaml" -apiVersion: x.symphony.k8s.aws/v1alpha1 +apiVersion: kro.run/v1alpha1 kind: ResourceGroup metadata: - name: deploymentservice.x.symphony.k8s.aws + name: deploymentservice spec: apiVersion: v1alpha1 kind: DeploymentService @@ -16,38 +16,38 @@ spec: spec: name: string resources: - - name: deployment - definition: - apiVersion: apps/v1 - kind: Deployment - metadata: - name: ${spec.name} - spec: - replicas: 1 - selector: - matchLabels: - app: deployment - template: - metadata: - labels: + - name: deployment + definition: + apiVersion: apps/v1 + kind: Deployment + metadata: + name: ${spec.name} + spec: + replicas: 1 + selector: + matchLabels: app: deployment - spec: - containers: - - name: ${spec.name}-deployment - image: nginx - ports: - - containerPort: 80 - - name: service - definition: - apiVersion: v1 - kind: Service - metadata: - name: ${spec.name} - spec: - selector: - app: deployment - ports: - - protocol: TCP - port: 80 - targetPort: 80 -``` \ No newline at end of file + template: + metadata: + labels: + app: deployment + spec: + containers: + - name: ${spec.name}-deployment + image: nginx + ports: + - containerPort: 80 + - name: service + definition: + apiVersion: v1 + kind: Service + metadata: + name: ${spec.name} + spec: + selector: + app: deployment + ports: + - protocol: TCP + port: 80 + targetPort: 80 +``` diff --git a/website/docs/examples/ekscluster.md b/website/docs/examples/ekscluster.md index 31e74ffe..fd816a66 100644 --- a/website/docs/examples/ekscluster.md +++ b/website/docs/examples/ekscluster.md @@ -5,10 +5,10 @@ sidebar_position: 10 # EKSCluster ```yaml title="ekscluster-rg.yaml" -apiVersion: x.symphony.k8s.aws/v1alpha1 +apiVersion: kro.run/v1alpha1 kind: ResourceGroup metadata: - name: ekscluster.x.symphony.k8s.aws + name: kro.run/v1alpha1 spec: # CRD Definition apiVersion: v1alpha1 @@ -19,136 +19,136 @@ spec: name: string version: string numNodes: integer - + # resources resources: - - name: clusterVPC - definition: - apiVersion: ec2.services.k8s.aws/v1alpha1 - kind: VPC - metadata: - name: cluster-vpc-${spec.name} - spec: - cidrBlocks: - - 192.168.0.0/16 - enableDNSHostnames: false - enableDNSSupport: true + - name: clusterVPC + definition: + apiVersion: ec2.services.k8s.aws/v1alpha1 + kind: VPC + metadata: + name: cluster-vpc-${spec.name} + spec: + cidrBlocks: + - 192.168.0.0/16 + enableDNSHostnames: false + enableDNSSupport: true + + - name: subnetAZA + definition: + apiVersion: ec2.services.k8s.aws/v1alpha1 + kind: Subnet + metadata: + name: cluster-subnet-a-${spec.name} + spec: + availabilityZone: us-west-2a + cidrBlock: 192.168.0.0/18 + vpcID: ${clusterVPC.status.vpcID} - - name: subnetAZA - definition: - apiVersion: ec2.services.k8s.aws/v1alpha1 - kind: Subnet - metadata: - name: cluster-subnet-a-${spec.name} - spec: - availabilityZone: us-west-2a - cidrBlock: 192.168.0.0/18 - vpcID: ${clusterVPC.status.vpcID} + - name: securityGroup + definition: + apiVersion: ec2.services.k8s.aws/v1alpha1 + kind: SecurityGroup + metadata: + name: cluster-security-group-${spec.name} + spec: + vpcID: ${clusterVPC.status.vpcID} + name: my-eks-cluster-sg-${spec.name} + description: something something - - name: securityGroup - definition: - apiVersion: ec2.services.k8s.aws/v1alpha1 - kind: SecurityGroup - metadata: - name: cluster-security-group-${spec.name} - spec: - vpcID: ${clusterVPC.status.vpcID} - name: my-eks-cluster-sg-${spec.name} - description: something something + - name: subnetAZB + definition: + apiVersion: ec2.services.k8s.aws/v1alpha1 + kind: Subnet + metadata: + name: cluster-subnet-b-${spec.name} + spec: + availabilityZone: us-west-2b + cidrBlock: 192.168.64.0/18 + vpcID: ${clusterVPC.status.vpcID} - - name: subnetAZB - definition: - apiVersion: ec2.services.k8s.aws/v1alpha1 - kind: Subnet - metadata: - name: cluster-subnet-b-${spec.name} - spec: - availabilityZone: us-west-2b - cidrBlock: 192.168.64.0/18 - vpcID: ${clusterVPC.status.vpcID} + - name: clusterRole + definition: + apiVersion: iam.services.k8s.aws/v1alpha1 + kind: Role + metadata: + name: cluster-role-${spec.name} + spec: + name: cluster-role-${spec.name} + policies: + - arn:aws:iam::aws:policy/AmazonEKSClusterPolicy + assumeRolePolicyDocument: | + { + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "Service": "eks.amazonaws.com" + }, + "Action": "sts:AssumeRole" + } + ] + } - - name: clusterRole - definition: - apiVersion: iam.services.k8s.aws/v1alpha1 - kind: Role - metadata: - name: cluster-role-${spec.name} - spec: - name: cluster-role-${spec.name} - policies: - - arn:aws:iam::aws:policy/AmazonEKSClusterPolicy - assumeRolePolicyDocument: | - { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "Service": "eks.amazonaws.com" - }, - "Action": "sts:AssumeRole" - } - ] - } + - name: nodeRole + definition: + apiVersion: iam.services.k8s.aws/v1alpha1 + kind: Role + metadata: + name: cluster-node-role-${spec.name} + spec: + name: cluster-node-role-${spec.name} + policies: + - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy + - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly + - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy + assumeRolePolicyDocument: | + { + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "Service": "ec2.amazonaws.com" + }, + "Action": "sts:AssumeRole" + } + ] + } - - name: nodeRole - definition: - apiVersion: iam.services.k8s.aws/v1alpha1 - kind: Role - metadata: - name: cluster-node-role-${spec.name} - spec: - name: cluster-node-role-${spec.name} - policies: - - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy - - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly - - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy - assumeRolePolicyDocument: | - { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "Service": "ec2.amazonaws.com" - }, - "Action": "sts:AssumeRole" - } - ] - } + - name: cluster + definition: + apiVersion: eks.services.k8s.aws/v1alpha1 + kind: Cluster + metadata: + name: cluster-${spec.name} + spec: + name: cluster-${spec.name} + roleARN: ${clusterRole.status.ackResourceMetadata.arn} + version: ${spec.version} + resourcesVPCConfig: + subnetIDs: + - ${subnetAZA.status.subnetID} + - ${subnetAZB.status.subnetID} - - name: cluster - definition: - apiVersion: eks.services.k8s.aws/v1alpha1 - kind: Cluster - metadata: - name: cluster-${spec.name} - spec: - name: cluster-${spec.name} - roleARN: ${clusterRole.status.ackResourceMetadata.arn} - version: ${spec.version} - resourcesVPCConfig: - subnetIDs: + - name: nodegroup + definition: + apiVersion: eks.services.k8s.aws/v1alpha1 + kind: Nodegroup + metadata: + name: nodegroup-${spec.name} + spec: + name: nodegroup-${spec.name} + clusterName: cluster-${spec.name} + subnets: - ${subnetAZA.status.subnetID} - ${subnetAZB.status.subnetID} - - - name: nodegroup - definition: - apiVersion: eks.services.k8s.aws/v1alpha1 - kind: Nodegroup - metadata: - name: nodegroup-${spec.name} - spec: - name: nodegroup-${spec.name} - clusterName: cluster-${spec.name} - subnets: - - ${subnetAZA.status.subnetID} - - ${subnetAZB.status.subnetID} - nodeRole: ${nodeRole.status.ackResourceMetadata.arn} - updateConfig: - maxUnavailable: 1 - scalingConfig: - minSize: ${spec.numNodes} - maxSize: ${spec.numNodes} - desiredSize: ${spec.numNodes} -``` \ No newline at end of file + nodeRole: ${nodeRole.status.ackResourceMetadata.arn} + updateConfig: + maxUnavailable: 1 + scalingConfig: + minSize: ${spec.numNodes} + maxSize: ${spec.numNodes} + desiredSize: ${spec.numNodes} +``` diff --git a/website/docs/examples/empty.md b/website/docs/examples/empty.md index 54bd9e08..26d93627 100644 --- a/website/docs/examples/empty.md +++ b/website/docs/examples/empty.md @@ -5,10 +5,10 @@ sidebar_position: 0 # Empty ResourceGroup ```yaml title="no-resources-rg.yaml" -apiVersion: x.symphony.k8s.aws/v1alpha1 +apiVersion: kro.run/v1alpha1 kind: ResourceGroup metadata: - name: noop.x.symphony.k8s.aws + name: kro.run/v1alpha1 spec: apiVersion: v1alpha1 kind: Noop @@ -16,4 +16,4 @@ spec: spec: name: string | required=true resources: [] -``` \ No newline at end of file +``` diff --git a/website/docusaurus.config.ts b/website/docusaurus.config.ts index 4205a433..5400c443 100644 --- a/website/docusaurus.config.ts +++ b/website/docusaurus.config.ts @@ -3,8 +3,8 @@ import type { Config } from "@docusaurus/types"; import type * as Preset from "@docusaurus/preset-classic"; const config: Config = { - title: "Symphony", - tagline: "All purpose glue for Kubernetes resources", + title: "KRO", + tagline: "Kube Runtime Orchestrator", // The Melodious Kubernetes Integrator // Cementing Your Kubernetes Infrastructure // Connecting the Dots in Your Kubernetes Environment @@ -20,7 +20,7 @@ const config: Config = { // GitHub pages deployment config. // If you aren't using GitHub pages, you don't need these. organizationName: "awslabs", // Usually your GitHub org/user name. - projectName: "private-symphony", // Usually your repo name. + projectName: "kro", // Usually your repo name. onBrokenLinks: "throw", onBrokenMarkdownLinks: "warn", @@ -59,7 +59,7 @@ const config: Config = { themeConfig: { // Replace with your project's social card - image: "img/symphony.svg", + image: "img/kro.svg", docs: { sidebar: { hideable: false, @@ -67,13 +67,13 @@ const config: Config = { }, }, navbar: { - title: "Symphony", + title: "KRO", hideOnScroll: true, - logo: { - alt: "My Site Logo", - src: "img/logo-light.svg", - srcDark: "img/logo-dark.svg", - }, + /* logo: { + alt: "KRO Logo", + src: "img/kro-light.svg", + srcDark: "img/kro-dark.svg", + }, */ items: [ { type: "docSidebar", @@ -109,7 +109,7 @@ const config: Config = { ], }, { - href: "https://github.com/awslabs/private-symphony", + href: "https://github.com/awslabs/kro", position: "right", className: "header-github-link", "aria-label": "GitHub repository", @@ -133,7 +133,7 @@ const config: Config = { items: [ { label: "Slack", - href: "https://github.com/awslabs/private-symphony", + href: "https://github.com/awslabs/kro", }, ], }, @@ -142,21 +142,21 @@ const config: Config = { items: [ { label: "GitHub", - href: "https://github.com/awslabs/private-symphony", + href: "https://github.com/awslabs/kro", }, ], }, ], copyright: `© ${new Date().getFullYear()} Amazon.com, Inc. or its affiliates. All rights reserved.`, }, - announcementBar: { + /* announcementBar: { id: `beta announcement`, // content: `⭐️ If you like Docusaurus, give it a star on GitHub and follow us on Twitter `, // content: `🎉️ Docusaurus v is out! 🥳️`, - content: ` ⚠️ This is a private preview version of Symphony. Do not expose to public networks. `, + content: ` ⚠️ This is a private preview version of KRO. Do not expose to public networks. `, backgroundColor: "#ff2617", textColor: "white", - }, + }, */ prism: { theme: prismThemes.github, darkTheme: prismThemes.github, @@ -166,4 +166,3 @@ const config: Config = { }; export default config; -// ' This a private preview version of Symphony. Please do not expose to public networks.', diff --git a/website/package-lock.json b/website/package-lock.json index 7dca1f9f..9db11b76 100644 --- a/website/package-lock.json +++ b/website/package-lock.json @@ -1,11 +1,11 @@ { - "name": "symphony-docs", + "name": "kro-docs", "version": "0.0.0", "lockfileVersion": 3, "requires": true, "packages": { "": { - "name": "symphony-docs", + "name": "kro-docs", "version": "0.0.0", "dependencies": { "@docusaurus/core": "3.5.2", diff --git a/website/package.json b/website/package.json index 345b4d88..a8ebae1f 100644 --- a/website/package.json +++ b/website/package.json @@ -1,5 +1,5 @@ { - "name": "symphony-docs", + "name": "kro-docs", "version": "0.0.0", "private": true, "scripts": { @@ -47,4 +47,4 @@ "engines": { "node": ">=18.0" } -} \ No newline at end of file +} diff --git a/website/src/components/HomepageFeatures/index.tsx b/website/src/components/HomepageFeatures/index.tsx index fe8e1206..5e9d3e7a 100644 --- a/website/src/components/HomepageFeatures/index.tsx +++ b/website/src/components/HomepageFeatures/index.tsx @@ -1,72 +1,79 @@ -import clsx from 'clsx'; -import Heading from '@theme/Heading'; -import styles from './styles.module.css'; -import { useColorMode } from '@docusaurus/theme-common' +import clsx from "clsx"; +import Heading from "@theme/Heading"; +import styles from "./styles.module.css"; +import { useColorMode } from "@docusaurus/theme-common"; type FeatureItem = { title: string; scale: number; id: string; fill: string; - Svg: React.ComponentType>; + Svg: React.ComponentType>; description: JSX.Element; }; const FeatureList: FeatureItem[] = [ { - title: 'Powerful Abstractions', - id: 'benzene-ring-svgrepo-com', - fill: 'white', + title: "Powerful Abstractions", + id: "benzene-ring-svgrepo-com", + fill: "white", scale: 0.7, - Svg: require('@site/static/img/resources.svg').default, + Svg: require("@site/static/img/resources.svg").default, description: ( <> Create powerful abstractions that encapsulate complex Kubernetes - resources, enabling easier management and reuse across your organization. + resources, enabling easier management and reuse across your + organization. ), }, { - title: 'Effortless Orchestration', - Svg: require('@site/static/img/qrcode.svg').default, - id: 'qr-code-svgrepo-com', - fill: 'a2', + title: "Effortless Orchestration", + Svg: require("@site/static/img/qrcode.svg").default, + id: "qr-code-svgrepo-com", + fill: "a2", scale: 0.6, description: ( <> - Symphony streamlines Kubernetes complexity, allowing you to manage resources + KRO streamlines Kubernetes complexity, allowing you to manage resources intuitively and focus on developing your application, not wrestling with YAML files. ), }, { - title: 'Seamless Scalability', + title: "Seamless Scalability", scale: 0.6, - id: 'scale-svgrepo-com', - fill: 'white', - Svg: require('@site/static/img/expand-arrows.svg').default, + id: "scale-svgrepo-com", + fill: "white", + Svg: require("@site/static/img/expand-arrows.svg").default, description: ( <> - Symphony effortlessly scales your resource management from simple deployments + KRO effortlessly scales your resource management from simple deployments to complex, multi-service architectures. ), }, ]; -function Feature({scale, fill, id, title, Svg, description}: FeatureItem) { - const {colorMode} = useColorMode() - if ( colorMode === 'light' ) { - fill = 'var(--main-color)'; - } else if ( colorMode === 'dark') { - fill = 'var(--main-color-dark)'; +function Feature({ scale, fill, id, title, Svg, description }: FeatureItem) { + const { colorMode } = useColorMode(); + if (colorMode === "light") { + fill = "var(--main-color)"; + } else if (colorMode === "dark") { + fill = "var(--main-color-dark)"; } return ( -
+
- +
{title} diff --git a/website/src/pages/index.tsx b/website/src/pages/index.tsx index e00c6c72..8025a223 100644 --- a/website/src/pages/index.tsx +++ b/website/src/pages/index.tsx @@ -1,35 +1,39 @@ -import clsx from 'clsx'; -import Link from '@docusaurus/Link'; -import useDocusaurusContext from '@docusaurus/useDocusaurusContext'; -import Layout from '@theme/Layout'; -import HomepageFeatures from '@site/src/components/HomepageFeatures'; -import Heading from '@theme/Heading'; +import clsx from "clsx"; +import Link from "@docusaurus/Link"; +import useDocusaurusContext from "@docusaurus/useDocusaurusContext"; +import Layout from "@theme/Layout"; +import HomepageFeatures from "@site/src/components/HomepageFeatures"; +import Heading from "@theme/Heading"; -import styles from './index.module.css'; +import styles from "./index.module.css"; function HomepageHeader() { const { siteConfig } = useDocusaurusContext(); return ( -
+
{siteConfig.title} -

{siteConfig.tagline}

+

+ {siteConfig.tagline} +

+ to="/docs/docs/overview" + > Get started + to="https://github.com/awslabs/kro" + > Go to Github
-
+
); } @@ -38,7 +42,8 @@ export default function Home(): JSX.Element { return ( + description="Description will go into a meta tag in " + >