KubePattern

Appearance

The Pattern Registry ​

The KubePattern Registry (kubepattern/registry) is the public collection of Patterns, stored, versioned and shared as plain YAML manifests. It lets teams share what a defect looks like, how to detect it and how to fix it, in a standard, machine-readable format.

How to use the registry ​

  1. Browse the registry. Patterns are grouped by the application they analyse. Pick the folders of the platforms you run.
  2. Apply a pattern. A Pattern is a custom resource: kubectl apply -f <pattern-file.yaml>. Patterns are cluster-scoped, so no namespace is needed.
  3. Read the results. At the next run, every match becomes a Smell. Fix the problem and the Smell disappears on the following run.

Not in a tagged release yet

Some patterns of the registry use constructs of the Pattern language that arrive with the next release, such as [@], defaults, transforms or kind: "*". To use them now, see Try unreleased features.

Do not apply them to an older engine. Its linter rejects some of them, such as a kind: "*" without plural, but it does not know the others. A [@] path then reads nothing, and a default is ignored, so under matchNone such a pattern can report every target.

Registry structure ​

text
registry/
├── kubernetes/              # one folder per application
│   ├── patterns/
│   │   ├── naked-pod.yaml   # one Pattern per file
│   │   └── ...
│   └── doc/
│       └── naked-pod.md     # optional documentation of a Pattern
├── krateo/
│   ├── patterns/
│   ├── doc/
│   └── tests/               # optional manifests to try a Pattern against
├── ...
├── LICENSE
└── README.md
  • patterns/ holds the Pattern manifests, one per file.
  • doc/ holds human-readable documentation: the problem a pattern addresses, why it matters, and how to fix it.
  • tests/ holds manifests that reproduce the smell, to check that a pattern detects it.

Create your own registry ​

The official registry holds common patterns, but you can keep the ones specific to your organisation in a registry of your own.

  1. Set up a repository on GitHub, GitLab or any Git host.
  2. Organise it like the official one: one folder per application, with patterns/, and doc/ and tests/ where they help.
  3. Write the patterns following the Pattern reference, and document them.
  4. Deliver them with GitOps, like any other manifest: Argo CD or Flux can sync the patterns/ folders to your clusters.

Patterns that are useful beyond your organisation are welcome in the official registry. See Contributing.