Kubernetes
configuration
relative paths
DevOps
container orchestration

Use relative paths in Kubernetes config

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

Relative paths can work in Kubernetes-related config, but only in places where the consuming tool actually reads files from the local filesystem. The most common valid case is kubeconfig, where file references such as certificates and keys can be relative to the kubeconfig file itself.

Relative Paths in kubeconfig

A kubeconfig file can reference local certificate and key files with fields such as:

  • 'certificate-authority'
  • 'client-certificate'
  • 'client-key'

Example:

yaml
1apiVersion: v1
2kind: Config
3clusters:
4  - name: dev
5    cluster:
6      server: https://example-cluster:6443
7      certificate-authority: certs/ca.crt
8users:
9  - name: dev-user
10    user:
11      client-certificate: certs/user.crt
12      client-key: certs/user.key
13contexts:
14  - name: dev
15    context:
16      cluster: dev
17      user: dev-user
18current-context: dev

In practice, those relative paths are resolved relative to the kubeconfig file location, not relative to whatever shell directory you happened to be in when you ran kubectl.

That makes a checked-in directory layout portable, which is usually the main reason people want relative paths in the first place.

Why This Is Useful

Using relative paths in kubeconfig helps when you keep a config bundle together:

  • one kubeconfig file
  • one certs directory
  • optional helper scripts nearby

That structure is easier to move between machines and easier to keep under version control, assuming the certificates themselves are handled appropriately.

A layout like this is common:

text
1project/
2  kubeconfig.yaml
3  certs/
4    ca.crt
5    user.crt
6    user.key

Then commands such as the following work naturally:

bash
kubectl --kubeconfig ./kubeconfig.yaml get pods

Do Not Generalize This to Every Kubernetes YAML Field

A common misunderstanding is assuming that any file-looking path in Kubernetes YAML can be relative in the same way. That is not generally true.

For example:

  • a Pod manifest does not read local machine files at apply time just because you wrote a relative path in some random field
  • volume mounts refer to paths inside containers or nodes, not paths relative to the manifest file
  • most resource specs describe cluster state, not local file inclusion

So the safe rule is: relative paths are meaningful only where the specific tool explicitly supports local file references.

Kustomize Is a Different Case

Kustomize also uses relative paths heavily, but that is a Kustomize feature, not a generic Kubernetes API behavior. In kustomization.yaml, entries such as resources, patches, and generators are commonly relative to the kustomization file.

Example:

yaml
1resources:
2  - ../base
3patches:
4  - patch-deployment.yaml

This is valid because Kustomize is building manifests from local files before talking to the cluster.

So if someone says "relative paths work in Kubernetes config", they may actually mean either:

  • kubeconfig path references
  • Kustomize file references

Those are not the same thing, and mixing them up leads to confusion.

Prefer Embedded Data When Portability Matters Most

For kubeconfig files, another option is embedding certificate data directly as base64-encoded fields such as certificate-authority-data and client-certificate-data. That avoids path resolution entirely.

Relative paths are nice when you want readable local bundles. Embedded data is nice when you want a single self-contained kubeconfig file.

Choose based on how the config is distributed and maintained.

Common Pitfalls

  • Assuming all Kubernetes YAML supports relative local file paths in the same way kubeconfig does.
  • Forgetting that kubeconfig paths are resolved relative to the kubeconfig file, not the current shell directory.
  • Confusing kubeconfig behavior with Kustomize behavior.
  • Using relative paths for secret material without thinking about how the directory is distributed and secured.
  • Expecting Pod manifest fields such as container paths or mount paths to behave like local file references.

Summary

  • Relative paths are commonly valid in kubeconfig for certificate and key file references.
  • Those paths are resolved relative to the kubeconfig file location.
  • Kustomize also supports relative paths, but that is a build-time tool feature.
  • Most ordinary Kubernetes resource fields do not interpret local relative file paths.
  • Use the tool-specific path model that actually applies instead of assuming all YAML fields behave the same way.

Course illustration
Course illustration

All Rights Reserved.