Deliver intentions to Kubernetes and Clouds
In this version, kusion apply supports specifying the port of the application to forward with the --port-forward option. After the application resources are deployed, Kusion CLI will automatically forward the local port with the same number to the corresponding pod port of the application in the targeted Kubernetes cluster, which makes it easier for users to debug their application. @liu-hm19
In this version, we added the kusion project and kusion stack sub commands for a better project and stack lifecycle management, facilitating the creation of new Project and Stack. A new stack can be created based on the existing ones, allowing users to quickly initiate a new set of application configurations. @liu-hm19
In Kusion v0.11.0, application resources will by default be created in the namespace with the same name as the project. In this version, we added supports for customized namespaces. Users now can specify a namespace in the extension fields of project.yaml and stack.yaml files, and the application resources will be created in the specified namespace accordingly. @adohe
In this version, we optimized the version management of Kusion Module OCI artifacts for kusion mod push cmd and introduced the support for multiple operating systems and architectures. @SparkYuan
The definitions, boundaries as well as their relationships of the Kusion core concepts, Project, Stack and Workspace, have been updated.
kusionstack/kusion:v0.11.1
mod push by @SparkYuan in https://github.com/KusionStack/kusion/pull/1080
Full Changelog: https://github.com/KusionStack/kusion/compare/v0.11.0...v0.11.1-rc.1
In v0.10.0, we have introduced the collaboration paradigm between Application Developers and Platform Engineers. Here we further improve the relevant AppConfiguration model and Kusion Module extension mechanism. A Kusion module is a reusable building block designed by platform engineers to standardize application deployments and enable app developers to self-service, usually including a module schema and a module generator. We update the AppConfiguration model and open the accessories field to support various modules adding capabilities to application Workload. Some common modules like Network, MySQL, PostgreSQL, OpsRule and Monitoring have been built in by us. Meanwhile, we provide a Kusion Module development framework with which platform engineers can efficiently build their own customized modules, as well as the user guides for application developers. We also provide the kusion mod cmd for users to build and push local cross-platform module packages to remote repositories, such as Github Packages. @SparkYuan @ffforest @liu-hm19
The core workflow of Kusion CLI are getting some big changes. An internal demo application is embedded in simplified kusion init for users to get started with Kusion CLI more quickly. And kusion build has now been upgraded to kusion generate to adapt to using Kusion Modules to convert the users' Intent for workload accessories into the resource specification (Spec), support a versioned Spec storage. The interaction interfaces for kusion preview, kusion apply and kusion destroy has also been upgraded. @adohe @healthjyk @liu-hm19
In the previous version of Kusion, a Stack could only be bounded to the Workspace with the same name, both of which were tightly coupled. And now they have been decoupled, achieving a more flexible workspace management. Kusion provides a default workspace when no workspace is explicitly specified as the current workspace, and adds the kusion workspace switch cmd to switch the current workspace. @healthjyk
We add the kusion config cmd for users to configure the storage backend of Kusion CLI with more flexibility and capability, enhancing the support for Workspace, Spec and State stored in Local, MySQL, S3 and OSS. Users can now configure and manage different backend storages for different workspaces with Kusion CLI. @healthjyk
Kusion now supports the automatic installation of Terraform CLI, eliminating the need for users to manually install it. @liu-hm19
kusion init cmd no longer supports application templates.kusion build cmd has been upgraded to kusion generate.AppConfiguration and Workload models have been migrated from the catalog to the kam repository.kusionstack/kusion:v0.11.0
mod init by @SparkYuan in https://github.com/KusionStack/kusion/pull/945
Full Changelog: https://github.com/KusionStack/kusion/compare/v0.10.0...v0.11.0-rc.1
Introduce the collaboration paradigm between application developers and platform engineers. Due to the mixed configuration and unclear division of labor, the application developers have to face the high cognitive burden, while the platform engineers have great difficulty in standardization management. Hence, we make the huge upgrade —— proposing the collaboration paradigm between application developers and platform engineers and the core workflow, implementing the separation of concerns, to improve the efficiency and standardization.
The platform engineers are responsible for creating Kusion modules and maintaining workspaces. A module is a reusable building block, and contains two components: an application developer-oriented schema and a module generator. By the application developer-oriented schema, platform engineers shield the underlying complexity and achieve standardization.
The application developers are responsible to write AppConfiguration, which are composed of the developer-oriented and dead-simple schemas. There are few or even no complex configs for application developers, which reduce the cognitive burden of them.
For more detail, please refer to How Kusion Works?
Introduce workspace and integrate it into the Kusion core workflow. The workspace is a logical concept representing a target that a stack will be deployed to, which contains a set of configurations that can be reused by multiple stacks. We recommend workspaces grouped by SDLC phases (such as dev, staging, and prod) or cloud vendors (such as AWS, Azure, and Alibaba Cloud).
The workspace contains four types of configurations: modules, runtimes, backends and secretStore, while the configuration is organized in YAML. We provide command lines to get, show, create, update, and delete workspace.
For more detail, please refer to Workspace.
Upgrade secret management in the new collaboration paradigm, and support more providers. Define the new core workflow of secret management in the collaboration scenario. Support storing sensitive data in Vault, AWS, Azure and Alibaba Cloud.
For more detail, please refer to Secrets and Using Cloud Secrets Manager.
Revamp the AppConfiguration according to the collaboration paradigm. Stripping platform configuration, the AppConfiguration only contains application developer-oriented configs. Splitting Database schema into MySQL and PostgreSQL, for better user experience.
For more detail, please refer to AppConfiguration.
ProjectName when using kusion init.kusion apply --watch.kusion compile, use kusion buildto replace it.Spec, use Intent to replace it.kusion_state.yaml, not kusion_state.json.kusionstack/kusion:v0.10.0
kusionstack/kusion:0.10.0-rc.1
kusion build and deprecate the kusion compile to build the single-source-of-truth (Intent) by @SparkYuankubeconfig file path in stack.yaml by @liu-hm19monkey to mockey by @MrcopytuoAppConfiguration generator has been upgraded by @Wenfeng-GAOproject.yaml by @liu-hm19restartPolicy issue in the job generator by @adohekusion apply with --watch by @cr7258kusion compile has been deprecated and replaced with kusion build to generate the Intent
AppConfiguration generator as the default generator instead of KCL generatorFull Changelog: https://github.com/KusionStack/kusion/compare/v0.9.0...v0.9.1
kusion build and delete redundant commands by @SparkYuan in https://github.com/KusionStack/kusion/pull/608
spec to intent by @SparkYuan in https://github.com/KusionStack/kusion/pull/640
Full Changelog: https://github.com/KusionStack/kusion/compare/v0.9.1-beta...v0.9.1-rc
monkey to mockey by @MrcopytuoAppConfiguration generator has been upgraded by @Wenfeng-GAOkubeconfig file path in stack.yaml by @liu-hm19project.yaml by @liu-hm19kusionstack/kusion:v0.9.1-beta
Introducing the new declarative application configuration model - AppConfiguration! It is replacing the Server model in the past versions. We have received numerous feedback in the past that it's challenging to get the ball rolling with KusionStack. So we have revamped the mechanism significantly.
The AppConfiguration model intends to eventually cover application delivery and operational needs in its full lifecycle. Currently, we have introduced the ability to configure workloads, networking, database, monitoring, basic operational rules, etc. We will continuously iterate and extend the capability of AppConfiguration to carry out our vision.
The design document can be found here
KCL is still the choice of configuration language for the AppConfiguration model. KCL has advantages when authoring a complex configuration file with some of its core features such as abstraction and validations capabilities. The logic to render the application abstraction model to the infrastructure manifests are now written in go.
Introducing the capability to configure application monitoring as part of AppConfiguration model. You can now customize the scraping behavior via the monitoring field.
We have added better support for more cloud resources such as CLB, RDS on AWS and AliCloud. They can be provisioned at your fingertip as part of the AppConfiguration model.
In Kusion terminology, spec is the infrastructure specification that is generated by Kusion from the user-facing input. It represents the declarative intent from the user. Kusion now supports using the spec as an input to the preview and apply subcommand. This enables the integration and version control of declarative intent for the platform users.
Konfig repository has now been revamped into a samples repository. The schemas for AppConfiguration model will be managed in the Catalog repository.kusion compile is now in the complete spec format.kusionstack/kusion:v0.9.0
v0.6.0-alpha.1
v0.5.0