kubectl-slice: split Kubernetes YAMLs into files

• kubectl-slice: split Kubernetes YAMLs into files
  • Installation
    • Using krew
    • Download and install manually
  • Usage
  • Why kubectl-slice?
  • Passing configuration options to kubectl-slice
  • Including and excluding manifests from the output
  • Examples
  • Contributing & Roadmap

kubectl-slice is a tool that allows you to split a single multi-YAML Kubernetes manifest (with --input-file or -f), or a folder containing multiple manifests files (with --input-folder or -d, optionally with --recursive), into multiple subfiles using a naming convention you choose. This is done by parsing the YAML code and allowing you to access any key from the YAML object using Go Templates.

By default, kubectl-slice will split your files into multiple subfiles following this naming convention that you can configure to your liking:

{{.kind | lower}}-{{.metadata.name}}.yaml

That is, the Kubernetes kind -- in this case, the value Namespace -- lowercased, followed by a dash, followed by the resource name -- in this case, the value production:

namespace-production.yaml

If your YAML includes multiple files, for example:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-ingress
---
apiVersion: v1
kind: Namespace
metadata:
  name: production

Then the following files will be created:

$ kubectl-slice --input-file=input.yaml --output-dir=.
Wrote pod-nginx-ingress.yaml -- 58 bytes.
Wrote namespace-production.yaml -- 61 bytes.
2 files generated.

You can customize the file name to your liking, by using the --template flag.

Installation

kubectl-slice can be used as a standalone tool or through kubectl, as a plugin.

Using krew

kubectl-slice is available as a krew plugin.

To install, use the following command:

kubectl krew install slice

Download and install manually

Download the latest release for your platform from the Releases page, then extract and move the kubectl-slice binary to any place in your $PATH. If you have kubectl installed, you can use both kubectl-slice and kubectl slice (note in the later the absence of the -).

Usage

kubectl-slice allows you to split a YAML into multiple subfiles using a pattern.
For documentation, available functions, and more, visit: https://github.com/patrickdappollonio/kubectl-slice.

Usage:
  kubectl-slice [flags]

Examples:
  kubectl-slice -f foo.yaml -o ./ --include-kind Pod,Namespace
  kubectl-slice -f foo.yaml -o ./ --exclude-kind Pod
  kubectl-slice -f foo.yaml -o ./ --exclude-name *-svc
  kubectl-slice -f foo.yaml --exclude-name *-svc --stdout
  kubectl-slice -f foo.yaml --include Pod/* --stdout
  kubectl-slice -f foo.yaml --exclude deployment/kube* --stdout
  kubectl-slice -d ./ --recurse -o ./ --include-kind Pod,Namespace
  kubectl-slice -d ./ --recurse --stdout --include Pod/*
  kubectl-slice --config config.yaml

Flags:
      --allow-empty-kinds      if enabled, resources with empty kinds don't produce an error when filtering
      --allow-empty-names      if enabled, resources with empty names don't produce an error when filtering
  -c, --config string          path to the config file
      --dry-run                if true, no files are created, but the potentially generated files will be printed as the command output
      --exclude strings        resource name to exclude in the output (format <kind>/<name>, case insensitive, glob supported)
      --exclude-kind strings   resource kind to exclude in the output (singular, case insensitive, glob supported)
      --exclude-name strings   resource name to exclude in the output (singular, case insensitive, glob supported)
      --extensions strings     the extensions to look for in the input folder (default [.yaml,.yml])
  -h, --help                   help for kubectl-slice
      --include strings        resource name to include in the output (format <kind>/<name>, case insensitive, glob supported)
      --include-kind strings   resource kind to include in the output (singular, case insensitive, glob supported)
      --include-name strings   resource name to include in the output (singular, case insensitive, glob supported)
      --include-triple-dash    if enabled, the typical "---" YAML separator is included at the beginning of resources sliced
  -f, --input-file string      the input file used to read the initial macro YAML file; if empty or "-", stdin is used (exclusive with --input-folder)
  -d, --input-folder string    the input folder used to read the initial macro YAML files (exclusive with --input-file)
  -o, --output-dir string      the output directory used to output the splitted files
      --prune                  if enabled, the output directory will be pruned before writing the files
  -q, --quiet                  if true, no output is written to stdout/err
  -r, --recurse                if true, the input folder will be read recursively (has no effect unless used with --input-folder)
  -s, --skip-non-k8s           if enabled, any YAMLs that don't contain at least an "apiVersion", "kind" and "metadata.name" will be excluded from the split
      --sort-by-kind           if enabled, resources are sorted by Kind, a la Helm, before saving them to disk
      --stdout                 if enabled, no resource is written to disk and all resources are printed to stdout instead
  -t, --template string        go template used to generate the file name when creating the resource files in the output directory (default "{{.kind | lower}}-{{.metadata.name}}.yaml")
  -v, --version                version for kubectl-slice

Why kubectl-slice?

See why kubectl-slice? for more information.

Passing configuration options to kubectl-slice

Besides command-line flags, you can also use environment variables and a YAML configuration file to pass options to kubectl-slice. See the documentation for configuration options for details about both, including precedence.

Including and excluding manifests from the output

Including or excluding manifests from the output via metadata.name or kind is possible. Globs are supported in both cases. See the documentation for including and excluding items for more information.

Examples

See examples for more information.

Contributing & Roadmap

Pull requests are welcomed! So far, looking for help with the following items, which are also part of the roadmap:

• Adding unit tests
• Improving the YAML file-by-file parser, right now it works by buffering line by line
• Adding support to install through brew
• Adding new features marked as enhancement