> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Kustomize ApiVersion and Kind

> Explains why to explicitly set apiVersion and kind in kustomization.yaml to ensure compatibility and portability across Kustomize and kubectl versions, with examples and checking commands

Just like other Kubernetes resource manifests, a `kustomization.yaml` file can include the `apiVersion` and `kind` fields. While Kustomize will infer sensible defaults when those fields are omitted, declaring them explicitly is a best practice. Explicit fields make your intent clear and reduce the chance of breakage when different Kustomize or `kubectl` versions are used.

<Callout icon="lightbulb" color="#1CB2FE">
  Always specify `apiVersion` and `kind` in `kustomization.yaml` so your manifests remain explicit and portable across environments and Kustomize versions.
</Callout>

## Common apiVersion / kind values

| apiVersion | kind |
| - | - |
| `kustomize.config.k8s.io/v1beta1` | `Kustomization` |
| `kustomize.config.k8s.io/v1` | `Kustomization` |

Which one to use depends on the Kustomize implementation and release you are targeting. Newer Kustomize versions provide the `v1` group/version; older releases and some `kubectl`-bundled versions may default to `v1beta1`.

## Example kustomization.yaml (explicit)

```yaml theme={null}
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - deployment.yaml
  - service.yaml
```

Including these fields is especially helpful when:

* Sharing overlays or bases across teams and clusters.
* Pinning manifests to a known Kustomize behavior.
* Ensuring compatibility when switching between the standalone `kustomize` binary and the `kubectl kustomize`/`kubectl apply -k` built-in support.

## Checking your Kustomize implementation

* Standalone Kustomize binary:

```bash theme={null}
kustomize version
```

* If you rely on `kubectl`'s embedded Kustomize:

```bash theme={null}
kubectl version --client
```

Then check the corresponding `kubectl` release notes to understand which Kustomize API versions it supports.

## Compatibility guidance

* Match the `apiVersion` in your `kustomization.yaml` to a version supported by your target Kustomize implementation.
* If you use `kubectl apply -k` or `kubectl kustomize`, verify that your `kubectl` supports the Kustomize API version used in your manifest.
* When upgrading Kustomize or `kubectl`, test overlays in a staging environment to detect any behavior changes between `v1beta1` and `v1`.

## Quick reference commands

| Purpose | Command |
| - | - |
| Run standalone Kustomize | `kustomize build <dir>` |
| Apply kustomization with kubectl | `kubectl apply -k <dir>` |
| Check standalone Kustomize version | `kustomize version` |
| Check kubectl client version | `kubectl version --client` |

## Links and references

* [Kustomize documentation](https://kubectl.docs.kubernetes.io/references/kustomize/)
* [Kustomize GitHub repository](https://github.com/kubernetes-sigs/kustomize)
* [kubectl documentation](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands)

<CardGroup>
  <Card title="Watch Video" icon="video" cta="Learn more" href="https://learn.kodekloud.com/user/courses/cka-certification-course-certified-kubernetes-administrator/module/031e84b8-bcbc-4f39-94d6-66d93b05bddc/lesson/0a9df343-8d0f-4db4-a85e-15945d53ef14" />
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.