You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hit the like (👍) or dislike (👎) button to let us know what you think about this feature.
Feel free to ask any clarifying questions or suggest enhancements.
This is just a proposal doc and intentionally doesn’t focus on technical details but rather on customer experience. If the proposal is accepted we will publish a detailed RFC where you’ll get a chance to provide more feedback.
With cdk8s, customers can create reusable and customizable constructs that synthesize into a Kubernetes manifest to be deployed at a future date. These constructs can then be published to standard package managers in the form of code libraries. This allows creating abstractions that reduce complexity and enforce best practices.
Currently, the way to consume those libraries (i.e produce a Kubernetes manifest out of them) is as follows:
cdk8s init
Install dependencies
Edit the main file.
cdk8s synth (possibly compile before as well, depending on the language)
In cases where a cdk8s application consists solely of instantiating a single construct, we feel this workflow can be a bit tedious, and introduces a maintenance burden that can be avoided. For example, say that we want to deploy a redis cluster using the cdk8s-redis library. We would have to create a cdk8s application and write code similar to this:
This type of work is undifferentiated, and can be automated. We propose to simplify these use cases by allowing the cdk8s synth command to accept a package URL and an arguments file:
Where the args.yaml file will (most likely) contain:
replicas: 4
Running the above command will produce the desired manifest. This command can then be easily integrated into scripts or workflows that simply want to utilize a cdk8s library.
Combine this feature with #1196, and we will have a single line command that can create a helm chart from a remote cdk8s library:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
With cdk8s, customers can create reusable and customizable constructs that synthesize into a Kubernetes manifest to be deployed at a future date. These constructs can then be published to standard package managers in the form of code libraries. This allows creating abstractions that reduce complexity and enforce best practices.
Currently, the way to consume those libraries (i.e produce a Kubernetes manifest out of them) is as follows:
cdk8s init
cdk8s synth
(possibly compile before as well, depending on the language)In cases where a cdk8s application consists solely of instantiating a single construct, we feel this workflow can be a bit tedious, and introduces a maintenance burden that can be avoided. For example, say that we want to deploy a redis cluster using the cdk8s-redis library. We would have to create a cdk8s application and write code similar to this:
This type of work is undifferentiated, and can be automated. We propose to simplify these use cases by allowing the
cdk8s synth
command to accept a package URL and an arguments file:cdk8s synth --package https://www.npmjs.com/package/cdk8s-redis/v/0.1.536 --args args.yaml
Where the
args.yaml
file will (most likely) contain:Running the above command will produce the desired manifest. This command can then be easily integrated into scripts or workflows that simply want to utilize a cdk8s library.
Combine this feature with #1196, and we will have a single line command that can create a helm chart from a remote cdk8s library:
cdk8s synth --format helm --package <package-url> --args args.yaml
Some limitations will most likely exist:
Beta Was this translation helpful? Give feedback.
All reactions