Skip to main content

· 4 min read

What is KCL

KCL is an open-source, constraint-based record and functional language that enhances the writing of complex configurations, including those for cloud-native scenarios. It is hosted by the Cloud Native Computing Foundation (CNCF) as a Sandbox Project. With advanced programming language technology and practices, KCL is dedicated to promoting better modularity, scalability, and stability for configurations. It enables simpler logic writing and offers ease of automation APIs and integration with homegrown systems.

Several Ways to Deploy KCL Configuration to a cluster

cloud-native-tool-integration

Since KCL can output YAML/JSON files, theoretically, any method that supports deploying YAML/JSON configurations to a cluster can be used to deploy KCL configurations. Usually, KCL files are stored in Git or Module Registry for easy sharing among different roles and teams. However, KCL can do much more than that, and the main ways to deploy KCL configurations to a cluster are as follows.

  • Using kubectl: The most basic way to access a Kubernetes cluster is using Kubectl. We can directly deploy the Kubernetes YAML configuration files generated by KCL to the cluster using the kubectl apply command. This method is simple and suitable for deploying a small number of resources.
  • Using CI/CD tools: CI/CD tools (such as Jenkins, GitLab CI, CircleCI, ArgoCD, FluxCD, etc.) can be used to achieve GitOps automation deployment of Kubernetes YAML configuration files to the cluster. By defining CI/CD processes and configuration files, automated building and deployment to the cluster can be achieved.
  • Using tools that support KRM Function specification: Kubernetes Resource Model (KRM) Function allows users to use other languages, including KCL, to enhance YAML template and logic writing capabilities, such as writing conditions, loops, etc. These tools mainly include Kustomize, KPT, Crossplane, etc. Although Helm does not natively support KRM Function, we can combine Helm and Kustomize to achieve it.
  • Using client/runtime custom abstract configuration tools for deployment: KusionStack, KubeVela, etc. Of course, KCL allows you to customize your preferred application configuration model.
  • Using KCL Operator with Kubernetes Mutation Webhook and Validation Webhook support for runtime configuration or policy writing.
  • Using configuration management tools: Combine configuration management tools (such as Puppet, Chef, Ansible, etc.) to automate the deployment of Kubernetes YAML configurations to the cluster. These tools can achieve dynamic configuration deployment by defining KCL templates and variables.

The reasons for KCL supporting multiple deployment methods and cloud-native tool integration are as follows:

  • Flexibility: Different deployment methods are suitable for different scenarios and needs, so providing multiple choices allows users to choose the most suitable way to deploy applications or configurations according to their specific situations.
  • Cloud-native tool ecosystem: Kubernetes is a widely used platform with a large ecosystem of tools and technologies. Supporting multiple deployment methods can provide users with more choices to meet their usage habits and technological preferences.
  • Specifications and standards: The Kubernetes community is working to promote standards and specifications, such as OAM, KRM Function specifications, and Helm Charts. By providing multiple support methods through a unified KRM KCL specification and KCL Module, different specification and standard requirements can be met.
  • Automation and integration: Some deployment methods can be integrated through automation tools and CI/CD pipelines to achieve automated deployment processes. Therefore, providing multiple ways can meet different automation and integration needs.

In conclusion, supporting multiple deployment methods can provide users with greater flexibility and choice, allowing them to deploy applications or configurations according to their needs and preferences. The specific usage of each deployment method is as follows:

Using Kubectl

https://kcl-lang.io/blog/2023-11-20-search-k8s-module-on-artifacthub

Using CI/CD Tools

https://kcl-lang.io/blog/2023-07-31-kcl-github-argocd-gitops

Using KRM Function

https://kcl-lang.io/blog/2023-10-23-cloud-native-supply-chain-krm-kcl-spec

Using Custom Abstract Configuration Tools

https://kcl-lang.io/blog/2023-12-15-kubevela-integration

Using KCL Operator

https://kcl-lang.io/docs/user_docs/guides/working-with-k8s/mutate-manifests/kcl-operator

Using Configuration Management Tools

https://github.com/kcl-lang/kcl/issues/952

· 8 min read

This blog is a review of the content of the KCL language part of the speech at the 2023 CNCF KCD ShenZhen meeting by KusionStack leader Dayuan Li and KCL project Maintainer Zhe Zong. The main content of this article is a review of the content of the KCL language part of the speech, the activity link: https://community.cncf.io/events/details/cncf-kcd-hangzhou-presents-kcd-shenzhen-2023/

In the cloud-native era, infrastructure as code (IaC) is the core of developer experience

In today's rapidly developing technical world, infrastructure as code (IaC) has become the key to automating and managing cloud resources, and IaC has also become the core part of developer experience, bringing convenience and efficiency, but it also brings a series of challenges.

intro-iac-en.png

First of all, application developers need to face the complex infrastructure and platform concepts provided by k8s, which has caused a high cognitive burden and affected the software delivery experience of higher-level application developers.

Therefore, we urgently need a way to reduce the cognitive burden of developers, provide efficient dynamic configuration management, and ensure the reliability of configuration through standard configuration testing and verification methods to ensure the efficiency and security of infrastructure.

Cloud Native Configuration and Policy Language - KCL

So we tried to design a new configuration language KCL to solve many of the problems mentioned above by designing the language syntax and enhancing the surrounding tools.

intro-kcl-en.png

KCL language starts from the three aspects of dynamic configuration management, configuration reliability verification and testing and reducing developer cognitive burden mentioned above. We propose three main design concepts, Mutation, Validation and Abstraction, and we also use these three design concepts as the core slogan of KCL homepage.

Around the three design concepts, KCL has done some design on the language syntax:

  • To use KCL for dynamic configuration management, the language side needs to provide syntaxes such as flow control and lambda expressions that can describe program behavior.
  • To do configuration reliability related verification and testing: you need to give this language the ability to check the configuration content through a strong type system, assert, check and other syntaxes to support the testing and verification process.
  • To reduce developer cognitive burden and development cost: KCL provides a Schema model to abstract the data structure. For developers, it shields unnecessary fields, and provides rich third-party library resources through the package management mechanism, reducing the cost of developers directly writing models.

KCL language features

I have listed some small code snippets that can reflect the language features in the ppt:

kcl-feature-en.png

At first, the leftmost picture shows the flow control, lambda expression, and python-style loop expression that are similar to general-purpose programming languages. Then, the middle picture shows the assert statement provided for verification and testing, and the check block of the schema. Through the strategy written in check, the fields in the schema can be checked. Finally, the rightmost picture is to use the schema to define the data structure and instantiate the configuration. And you can see that in this example, the strong type system of KCL has also demonstrated the ability to check the configuration type. If the type of a field is written incorrectly in the process of instantiating the configuration using the schema, the error will be checked at the compilation stage. The last picture is to use the third-party library of k8s to create an nginx pod. Some unnecessary fields have been shielded, and the application developer only needs to fill in a few fields to complete the configuration writing.

KCL & KRM & Dynamic Configuration Management

KCL provides some dynamic behaviors such as check, assert statements, type system, Schema abstraction, etc. However, when we try to use the above features for configuration management, we find that the language features of KCL alone are not enough. To solve the problems in the IaC field, we must also consider the stock configuration. It is obviously not a suitable way to push down all the stock configurations and use KCL to rebuild them, and it cannot be realized.

Therefore, in addition to working on language mechanisms, we also need to have the ability to integrate with the community ecology to make the role of KCL language features play on other configuration languages, so that KCL can truly solve the problems in the IaC field. Under the premise of minimizing the changes to the stock configuration, give full play to the role of KCL language features, and solve the problems of dynamic configuration, reliability verification, and reducing the cognitive burden of developers.

kcl-krm-en.png

Therefore, we proposed the KCL KRM specification, based on this specification, we can use the capabilities of the KCL language to dynamically configure, verify and abstract the resources in KRM.

KCL Ecological Integration

Based on the KCL & KRM specification, we have developed some peripheral tools to better integrate KCL with the surrounding tool ecology.

kcl-integration-en.png

  • Data structure import and export: KCL provides import/export tools, which support using KCL to import/export data structures from JsonSchema, Terraform, etc., to reduce the process of duplicating data modeling in the development process, and make KCL effect is applied to stock configuration.
  • Plugins: KCL provides plugins for tools such as kubectl, kustomize, helm/helmfile, etc. Users can choose the appropriate engine such as Kubectl, KusionStack, KubeVela or Helmfile according to different scenarios to combine with KCL to make the configuration effective to the cluster.
  • KCL Operator: Developed KCL Operator to integrate with Kubernetes, and automatically modify the configuration at runtime without the need to repeatedly develop Kubernetes Webhook to write a large amount of configuration processing logic.

KCL is built in a completely open cloud-native world. KCL is almost not strongly bound to any orchestration/engineering tools, and can provide API abstraction, combination and verification capabilities for both clients and runtimes at the same time.

KCL Toolchain

Although KCL is a domain language. KCL also provides a toolchain that is basically equivalent to the capabilities of general programming languages, such as formatting, testing, documentation , package management tools, etc. to help better write, understand and check the written configuration or strategy; through VS Code and other IDE plug-ins and Playground to reduce the cost of configuration writing and sharing; through Rust, Go, and Python multi-language SDK to automate the management and execution of configuration.

For IDE plug-ins, KCL currently mainly provides VS Code, IntelliJ and NeoVim. The three IDE plug-ins are based on the same KCL Language Server to implement the same capabilities such as completion, jump, hover, code refactoring, and formatting.

kcl-tools-en.png

Artifacthub & KCL

KCL has been integrated with ArtifactHub, which is used as the model market of KCL, providing more than 200+ KCL models, covering multiple aspects such as configuration editing, verification and model abstraction. If you are interested, you can take a look at whether there are models you are interested in, or if you have good ideas to share with everyone, you can also contribute your KCL package to ArtifactHub.

kcl-ah-en.png

Some practical cases

Finally, I will show some simple cases to of the use of KCL.

kcl-mut-en.png

At first, if the KCL Operator is installed in the cluster, then the configuration on the right can be mutated through the configuration file on the left. The behavior code is written in KCL in the source field, and the annotation is dynamically added to the configuration file on the right.

kcl-vet-en.png

Then, in this case, the configuration content generated by terraform plan is verified using the configuration verification tool kcl-vet provided by KCL.

kcl-abs-en.png

Finally, in this case, the abstraction of the configuration is demonstrated. We can get the Kubernetes manifests by directly writing the KCL program, or by writing the configuration using KCL & KRM and compiling it into the corresponding Kubernetes manifests.

Summary

KCL language is a domain language focusing on cloud-native configuration management. It provides a series of language features, such as strong type system, Schema abstraction, flow control, lambda expression, assert statement, check statement, etc., to solve the problems in the cloud-native configuration management field, such as dynamic configuration management, configuration reliability verification and testing, and reducing developer cognitive burden. At the same time, KCL also provides a series of peripheral tools, such as IDE plug-ins, ArtifactHub integration, KCL Operator, etc., to improve the development experience of developers and reduce development costs.

Other Resources

For more information about KCL, please refer to: