{"id":571,"date":"2018-10-17T15:07:49","date_gmt":"2018-10-17T15:07:49","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw93\/?p=571"},"modified":"2018-10-17T15:35:42","modified_gmt":"2018-10-17T15:35:42","slug":"introducing-kustomize-template-free-configuration-customization-for-kubernetes","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw93\/index.php\/2018\/10\/17\/introducing-kustomize-template-free-configuration-customization-for-kubernetes\/","title":{"rendered":"Introducing kustomize; Template-free Configuration Customization for Kubernetes"},"content":{"rendered":"

Introducing kustomize; Template-free Configuration Customization for Kubernetes<\/a><\/h3>\n

Authors: Jeff Regan (Google), Phil Wittrock (Google)<\/p>\n

If you run a Kubernetes environment, chances are you\u2019ve
\ncustomized a Kubernetes configuration \u2014 you\u2019ve copied
\nsome API object YAML files and editted them to suit
\nyour needs.<\/p>\n

But there are drawbacks to this approach \u2014 it can be
\nhard to go back to the source material and incorporate
\nany improvements that were made to it. Today Google is
\nannouncing kustomize<\/a>, a command-line tool
\ncontributed as a subproject<\/a> of SIG-CLI<\/a>. The tool
\nprovides a new, purely declarative<\/em> approach to
\nconfiguration customization that adheres to and
\nleverages the familiar and carefully designed
\nKubernetes API.<\/p>\n

Here\u2019s a common scenario. Somewhere on the internet you
\nfind someone\u2019s Kubernetes configuration for a content
\nmanagement system. It\u2019s a set of files containing YAML
\nspecifications of Kubernetes API objects. Then, in some
\ncorner of your own company you find a configuration for
\na database to back that CMS \u2014 a database you prefer
\nbecause you know it well.<\/p>\n

You want to use these together, somehow. Further, you
\nwant to customize the files so that your resource
\ninstances appear in the cluster with a label that
\ndistinguishes them from a colleague\u2019s resources who\u2019s
\ndoing the same thing in the same cluster.
\nYou also want to set appropriate values for CPU, memory
\nand replica count.<\/p>\n

Additionally, you\u2019ll want multiple variants<\/em> of the
\nentire configuration: a small variant (in terms of
\ncomputing resources used) devoted to testing and
\nexperimentation, and a much larger variant devoted to
\nserving outside users in production. Likewise, other
\nteams will want their own variants.<\/p>\n

This raises all sorts of questions. Do you copy your
\nconfiguration to multiple locations and edit them
\nindependently? What if you have dozens of development
\nteams who need slightly different variations of the
\nstack? How do you maintain and upgrade the aspects of
\nconfiguration that they share in common? Workflows
\nusing kustomize provide answers to these questions.<\/p>\n

Customization is reuse<\/h2>\n

Kubernetes configurations aren\u2019t code (being YAML
\nspecifications of API objects, they are more strictly
\nviewed as data), but configuration lifecycle has many
\nsimilarities to code lifecycle.<\/p>\n

You should keep configurations in version
\ncontrol. Configuration owners aren\u2019t necessarily the
\nsame set of people as configuration
\nusers. Configurations may be used as parts of a larger
\nwhole. Users will want to reuse<\/em> configurations for
\ndifferent purposes.<\/p>\n

One approach to configuration reuse, as with code
\nreuse, is to simply copy it all and customize the
\ncopy. As with code, severing the connection to the
\nsource material makes it difficult to benefit from
\nongoing improvements to the source material. Taking
\nthis approach with many teams or environments, each
\nwith their own variants of a configuration, makes a
\nsimple upgrade intractable.<\/p>\n

Another approach to reuse is to express the source
\nmaterial as a parameterized template. A tool processes
\nthe template\u2014executing any embedded scripting and
\nreplacing parameters with desired values\u2014to generate
\nthe configuration. Reuse comes from using different
\nsets of values with the same template. The challenge
\nhere is that the templates and value files are not
\nspecifications of Kubernetes API resources. They are,
\nnecessarily, a new thing, a new language, that wraps
\nthe Kubernetes API. And yes, they can be powerful, but
\nbring with them learning and tooling costs. Different
\nteams want different changes\u2014so almost every
\nspecification that you can include in a YAML file
\nbecomes a parameter that needs a value. As a result,
\nthe value sets get large, since all parameters (that
\ndon\u2019t have trusted defaults) must be specified for
\nreplacement. This defeats one of the goals of
\nreuse\u2014keeping the differences between the variants
\nsmall in size and easy to understand in the absence of
\na full resource declaration.<\/p>\n

A new option for configuration customization<\/h2>\n

Compare that to kustomize, where the tool\u2019s
\nbehavior is determined by declarative specifications
\nexpressed in a file called kustomization.yaml.<\/p>\n

The kustomize program reads the file and the
\nKubernetes API resource files it references, then emits
\ncomplete resources to standard output. This text output
\ncan be further processed by other tools, or streamed
\ndirectly to kubectl for application to a cluster.<\/p>\n

For example, if a file called kustomization.yaml
\ncontaining<\/p>\n

commonLabels:
\napp: hello
\nresources:
\n– deployment.yaml
\n– configMap.yaml
\n– service.yaml<\/p>\n

is in the current working directory, along with
\nthe three resource files it mentions, then running<\/p>\n

kustomize build<\/p>\n

emits a YAML stream that includes the three given
\nresources, and adds a common label app: hello to
\neach resource.<\/p>\n

Similarly, you can use a commonAnnotations<\/em> field to
\nadd an annotation to all resources, and a namePrefix<\/em>
\nfield to add a common prefix to all resource
\nnames. This trivial yet common customization is just
\nthe beginning.<\/p>\n

A more common use case is that you\u2019ll need multiple
\nvariants of a common set of resources, e.g., a
\ndevelopment<\/em>, staging<\/em> and production<\/em> variant.<\/p>\n

For this purpose, kustomize supports the idea of an
\noverlay<\/em> and a base<\/em>. Both are represented by a
\nkustomization file. The base declares things that the
\nvariants share in common (both resources and a common
\ncustomization of those resources), and the overlays
\ndeclare the differences.<\/p>\n

Here\u2019s a file system layout to manage a staging<\/em> and
\nproduction<\/em> variant of a given cluster app:<\/p>\n

someapp\/
\n\u251c\u2500\u2500 base\/
\n\u2502 \u251c\u2500\u2500 kustomization.yaml
\n\u2502 \u251c\u2500\u2500 deployment.yaml
\n\u2502 \u251c\u2500\u2500 configMap.yaml
\n\u2502 \u2514\u2500\u2500 service.yaml
\n\u2514\u2500\u2500 overlays\/
\n\u251c\u2500\u2500 production\/
\n\u2502 \u2514\u2500\u2500 kustomization.yaml
\n\u2502 \u251c\u2500\u2500 replica_count.yaml
\n\u2514\u2500\u2500 staging\/
\n\u251c\u2500\u2500 kustomization.yaml
\n\u2514\u2500\u2500 cpu_count.yaml<\/p>\n

The file someapp\/base\/kustomization.yaml specifies the
\ncommon resources and common customizations to those
\nresources (e.g., they all get some label, name prefix
\nand annotation).<\/p>\n

The contents of
\nsomeapp\/overlays\/production\/kustomization.yaml could
\nbe<\/p>\n

commonLabels:
\nenv: production
\nbases:
\n– ..\/..\/base
\npatches:
\n– replica_count.yaml<\/p>\n

This kustomization specifies a patch<\/em> file
\nreplica_count.yaml, which could be:<\/p>\n

apiVersion: apps\/v1
\nkind: Deployment
\nmetadata:
\nname: the-deployment
\nspec:
\nreplicas: 100<\/p>\n

A patch is a partial resource declaration, in this case
\na patch of the deployment in
\nsomeapp\/base\/deployment.yaml, modifying only the
\nreplicas<\/em> count to handle production traffic.<\/p>\n

The patch, being a partial deployment spec, has a clear
\ncontext and purpose and can be validated even if it\u2019s
\nread in isolation from the remaining
\nconfiguration. It\u2019s not just a context free tuple.<\/p>\n

To create the resources for the production variant, run<\/p>\n

kustomize build someapp\/overlays\/production<\/p>\n

The result is printed to stdout as a set of complete
\nresources, ready to be applied to a cluster. A
\nsimilar command defines the staging environment.<\/p>\n

In summary<\/h2>\n

With kustomize, you can manage an arbitrary number
\nof distinctly customized Kubernetes configurations
\nusing only Kubernetes API resource files. Every
\nartifact that kustomize uses is plain YAML and can
\nbe validated and processed as such. kustomize encourages
\na fork\/modify\/rebase workflow<\/a>.<\/p>\n

To get started, try the hello world<\/a> example.
\nFor discussion and feedback, join the mailing list<\/a> or
\nopen an issue<\/a>. Pull requests are welcome.<\/p>\n

Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Introducing kustomize; Template-free Configuration Customization for Kubernetes Authors: Jeff Regan (Google), Phil Wittrock (Google) If you run a Kubernetes environment, chances are you\u2019ve customized a Kubernetes configuration \u2014 you\u2019ve copied some API object YAML files and editted them to suit your needs. But there are drawbacks to this approach \u2014 it can be hard to … <\/p>\n

Continue reading “Introducing kustomize; Template-free Configuration Customization for Kubernetes”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-571","post","type-post","status-publish","format-standard","hentry","category-kubernetes"],"_links":{"self":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/571","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/comments?post=571"}],"version-history":[{"count":1,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/571\/revisions"}],"predecessor-version":[{"id":573,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/571\/revisions\/573"}],"wp:attachment":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/media?parent=571"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/categories?post=571"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/tags?post=571"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}