Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update rationale.md #3096

Merged
merged 4 commits into from
May 6, 2022
Merged

Update rationale.md #3096

merged 4 commits into from
May 6, 2022

Conversation

bgrant0607
Copy link
Contributor

@selfmanagingresource

I took a stab at updating the rationale. Next, I recommend moving it to precede the concept section of the book.


This enables WYSIWYG management of configuration similar to how the live state can be modified with traditional imperative tools:
Kpt enables WYSIWYG management of configuration similar to how the live state can be modified with traditional imperative tools, thus eliminating this dichtomy:
Copy link

@davidreuss davidreuss May 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dichotomy 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Clearly spellcheck would be useful.

Copy link

@davidreuss davidreuss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great update and explains differences of approach really well, and what makes kpt unique in the landscape.

@bgrant0607
Copy link
Contributor Author

Thanks for the review, @davidreuss. I've found that there's been a lot of confusion about where I'm trying to go with kpt and Configuration as Data, so I'm working to clarify that.

Copy link
Contributor

@justinsb justinsb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm - very nice!


Most Kubernetes users either manage their resources using conventional imperative graphical user interfaces, command-line tools (kubectl), and automation (e.g., Operators) that operate directly against Kubernetes APIs or IaC tools, such as Helm, Terraform, cdk8s, or one of the [dozens of other tools](https://docs.google.com/spreadsheets/d/1FCgqz1Ci7_VCz_wdh8vBitZ3giBtac_H8SBw4uxnrsE/edit#gid=0).
As companies expand the number of Kubernetes development and production clusters they use, creating and enforcing consistent configurations and security policies across a growing environment becomes difficult. At that point, the choice of management surface is no longer driven by preference, but by capabilities. To address this challenge, it is increasingly common for platform administrators to use “GitOps” methodology to deploy configuration consistently across clusters and environments with a version-controlled deployment process. Using the same principles as Kubernetes itself, GitOps reconciles the desired state of clusters with a set of Kubernetes declarative configuration files in a source control system, namely git.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: methodology -> methodologies (?).

Supernit: We should also decide how to do the line breaks here - all on one line makes it a little harder to review.

I think it might be easier to do follow-on PRs for these nits; I'll focus on the content.

@yuwenma yuwenma merged commit e10e624 into main May 6, 2022
@yuwenma yuwenma deleted the bgrant0607-rationale-1 branch May 6, 2022 16:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants