github.com/wmuizelaar/kpt@v0.0.0-20221018115725-bd564717b2ed/site/faq/README.md (about)

     1  # FAQ
     2  
     3  ### What is the roadmap for kpt?
     4  
     5  Please visit the [roadmap document] and the [kpt milestones].
     6  
     7  ### How is kpt different from other solutions?
     8  
     9  Think of configuration as an API or data in a database. kpt can operate on configuration
    10  in storage, git or OCI.
    11  
    12  Rather than expressing configuration AS code or templates that generate configuration,
    13  kpt represents [Configuration as Data]. In particular, it represents configuration
    14  as YAML or JSON objects adhering to [The Kubernetes Resource Model], the same as the
    15  live state in Kubernetes, which enables novel remedies to configuration drift.
    16  
    17  kpt uses an in-place transformation approach to customization: 
    18  read configuration in, modify it, and write it back.
    19  
    20  This enables interoperability of a variety of generators,
    21  transformers, and validators. One doesn’t have to make all changes through a monolithic
    22  generator implementation.
    23  
    24  By storing the result of config generators and transformers, automated mutations can be separated in time
    25  from use and other modifications. This enables generation via a UI, for example.
    26  It also is one enabler of in-place edits rather than patches or other programmatic overrides.
    27  
    28  Another ingredient in the secret sauce is the ability to upgrade from an upstream package
    29  despite downstream modifications. Conceptually it's like deriving and applying patches automatically.
    30  
    31  Combine these capabilities with the ability to operate on packages in bulk via APIs,
    32  and new operational capabilities are enabled. 
    33  
    34  ### What's the difference between kpt and kustomize?
    35  
    36  While both kpt and kustomize support customization of KRM resources via a transformation-based approach,
    37  there are important differences in both feature sets and the scopes of these projects. 
    38  
    39  _kustomize_
    40  
    41  - Builds the final configuration out of place, primarily using the [overlay pattern].
    42  - Treats base layers as immutable, but enables nearly arbitrary overrides.
    43  
    44  _kpt_
    45  
    46  - Optimizes for WYSIWYG configuration and in-place customization.
    47  - Allows edits to the configuration in-place without creating complex patches.
    48  - Supports rebase with resource merge strategy allowing for edited config to
    49    be updated.
    50  - Enables workflows that combine programmatic changes ([functions]) with manual
    51    edits.
    52  - Aims to support mutating and validating admission control on derived packages.
    53  - Also supports packages, [package orchestration], resource actuation, and GitOps.
    54  
    55  ### Do kpt and kustomize work together?
    56  
    57  The goal of kpt project is to provide a seamless UX spanning packaging,
    58  transformation, and actuation functionality. At the same time, kpt follows a modular
    59  design principle to make it possible to use each of its functionality
    60  independently if needed. For example:
    61  
    62  - You can use packaging without declaring functions
    63  - You can use imperative functions to operate on vanilla directories of Kubernetes
    64    resources
    65  - You can use apply logic without buying into the full packaging story (still
    66    need a minimal `Kptfile` though)
    67  
    68  We have created a [kustomize solution] which allows you to use kpt for packaging
    69  and actuation, and kustomize for customization.
    70  
    71  ### Why resource configuration as the artifact rather than templates or configuration DSLs?
    72  
    73  As explained in [Declarative application management in Kubernetes], using
    74  resource configuration provides a number of desirable properties:
    75  
    76  1. it clearly **represents the intended state** of the infrastructure
    77  
    78  2. it **aligns with how tools developed by the Kubernetes project are written**
    79     -- `kubectl`, `kustomize`, etc
    80  
    81  3. it enables **composition of different types of tools written in different
    82     languages**
    83  
    84     - any modern language can manipulate YAML / JSON structures, no need to adopt
    85       `go`
    86  
    87  4. it **supports static analysis and validation**
    88  
    89     - develop tools and processes to perform validation and linting
    90  
    91  5. it **supports programmatic modification**
    92  
    93     - develop CLIs and UIs for working with configuration rather than using `vim`
    94  
    95  6. it **supports display in UI and tools** which use either OpenAPI or the
    96     YAML/JSON directly.
    97  
    98  For a more complete explanation, see the [rationale].
    99  
   100  ### I really like DSL / templating solution X. Can I use it with kpt?
   101  
   102  Yes. kpt supports plugging in solutions which generate or manipulate
   103  configuration, e.g. from DSLs and templates. This may be performed using the
   104  [Functions Catalog]. The generated output may be modified directly, and merged
   105  when regenerated.
   106  
   107  ### I want to write high-level abstractions like CRDs, but on the client-side. Can I do this with kpt?
   108  
   109  Yes. kpt's architecture facilitates the developing programs which may generate
   110  or modify configuration. See the [Using Functions] for how to compose multiple
   111  programs together.
   112  
   113  ### What's with the name?
   114  
   115  kpt was inspired by `apt`, but with a Kubernetes focus. We wanted to uphold the
   116  tradition of naming tools to start with `k`, and also be short enough that you
   117  don't have to alias it. It is pronounced "kept".
   118  
   119  ### I still have questions. How do I contact you?
   120  
   121  [Please reach out!][contact]
   122  
   123  [Configuration as Data]:
   124    https://github.com/GoogleContainerTools/kpt/blob/main/docs/design-docs/06-config-as-data.md
   125  [package orchestration]:
   126    https://github.com/GoogleContainerTools/kpt/blob/main/docs/design-docs/07-package-orchestration.md
   127  [the kubernetes resource model]:
   128    https://github.com/kubernetes/design-proposals-archive/blob/main/architecture/resource-management.md
   129  [declarative application management in kubernetes]:
   130    https://github.com/kubernetes/design-proposals-archive/blob/main/architecture/declarative-application-management.md
   131  [rationale]: https://kpt.dev/guides/rationale
   132  [functions]: /reference/cli/fn/eval/
   133  [using functions]: /book/04-using-functions/
   134  [contact]: /contact/
   135  [functions catalog]: https://catalog.kpt.dev/
   136  [roadmap document]:
   137    https://github.com/GoogleContainerTools/kpt/blob/main/docs/ROADMAP.md
   138  [kpt milestones]: https://github.com/GoogleContainerTools/kpt/milestones
   139  [kustomize solution]:
   140    https://github.com/GoogleContainerTools/kpt/tree/main/package-examples/kustomize
   141  [kustomize]: https://kustomize.io
   142  [overlay pattern]:
   143    https://github.com/kubernetes-sigs/kustomize/tree/master/examples/multibases