You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
A lightweight tool to facilitate config reuse, designed for GitOps, config as data, and composition with other tools and formats.https://twitter.com/GoogleOSS/status/1245026820979859464 …
Configuration was noted as a hard, open problem in our Borg, Omega, and Kubernetes paper: https://research.google/pubs/pub44843/ , and there continues to be demand for innovation in the realm of declarative config/deployment automation. There are now more than 120 tools:https://docs.google.com/spreadsheets/d/1FCgqz1Ci7_VCz_wdh8vBitZ3giBtac_H8SBw4uxnrsE/edit …
Fragmentation has been exacerbated by user preferences to use familiar templating and programming languages, the simplest mechanisms that satisfy their needs, and as few tools as possible. Greater reusability of tool implementations and config itself would benefit everyone.
That’s one of the many reasons I am excited about kpt. kpt is a toolkit to help manage, examine, manipulate, customize, validate, and apply Kubernetes resource configuration files, both manually and programmatically.
One of the primary sets of capabilities that is required to enable configuration reuse is the ability to distribute/publish/share, compose, and update groups of configuration files, commonly known as packages.
git is the most common source of truth for declarative configuration files, and users are increasingly driving deployment workflows from changes in git, either with traditional CI/CD tools or dedicated GitOps tools. kpt facilitates declarative workflows directly around git.
The other main capability needed to enable reuse is the ability to customize configuration files for specific use cases. That’s where the most diverse preferences are evident. kpt supports generation, transformation, and validation functions written in any programming language.
kpt accomplishes this by representing configuration as data, specifically Kubernetes resources serialized as YAML or JSON. The configuration-as-data approach builds upon the design of the Kubernetes resource model (KRM): https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/resource-management.md …
It builds directly upon prior work in Kubernetes, such as https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/declarative-application-management.md …, bulk operations in kubectl (https://github.com/kubernetes/kubernetes/pull/1007/files …), apply (http://issues.k8s.io/1702 ), andhttps://github.com/kubernetes-sigs/kustomize …
Though it’s in its early stages, I hope that kpt will not only fill a gap in the existing tool landscape, but will also inspire more tools designed to interoperate with other configuration and deployment tools and workflows in the Kubernetes ecosystem.
Is there some overlap in what kpt and kustomize can do (in terms of customizing YAML)? When would you use one over the other?
This was my first question as well. We use Helm to generate manifests, and FluxCD with Kustomize to deploy workloads to our Kubernetes environments, and I'm a bit unclear if kpt would give us any added benefit.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
