Mastering Kubernetes Deployments with Kustomize: A Practical Guide

To publish an application on Kubernetes and expose it as a service, you need to configure Config APIs such as Deployment, Ingress, and Service, which are loosely coupled through Labels.

If you want tighter relationships between these Config APIs, you can create a higher‑level abstraction that combines them into a single configuration.

This abstraction also hides differences between API versions, allowing a single

kustz.yml

file to be compatible with multiple cluster versions and enabling smooth deployment or migration.

Kustomize

kustomize: https://kubectl.docs.kubernetes.io/guides/introduction/kustomize/

The official guide page is becoming cluttered.

In short, here is a minimal

kustomization.yaml

file:

<code>apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: demo-demo
resources:
  - deployment.yml
  - service.yml
  - ingress.yml</code>

apiVersion

and

kind

define the purpose of the file.

namespace

specifies the runtime environment for the service.

resources

imports external resources, which Kustomize renders and manages (e.g., patches).

Deployment, Pod and Container

Deployment is the most common workload that defines the desired state of Pods.

A Pod is the smallest scheduling unit in Kubernetes, defining network, storage, and permission information.

The actual execution unit is the Container, which runs the application.

Using

kubectl

you can generate a simple Deployment template:

<code>$ kubectl create deployment my-nginx --image nginx:alpine --dry-run=client -o yaml</code>

The resulting diagram shows three nested layers:

The outer red layer is the Deployment.

The middle blue layer is the Pod.

The inner green layer is the Container.

These layers are essentially nested dolls.

kustz

The

kustz

tool works like a Deployment, treating an application as a single unit and defining it in one file.

All configurations are centralized in a single file, making management of multiple resources easier.

The complex API structure becomes more semantic and simpler to configure.

<code># kustz.yml

namespace: demo-demo  # runtime namespace

service:  # define an application
  name: srv-webapp-demo
  image: docker.io/library/nginx:alpine
  replicas: 1
  envs:   # container environment variables
    pairs:
      key1: value1-123
  resources:
    cpu: 10m/20m
    memory: 10Mi/20Mi
  probes:  # container probes
    liveness:
      action: http://:80/liveness
  ports:  # Service ports
    - "80:80"  # cluster ip

## expose externally
ingress:
  - http://www.example.com/*
</code>

Note: The structure of the configuration files may be adjusted as development progresses.

With the

kustz.yml

file you define the complete configuration of a service, then the

kustz

tool converts it into

kustomization.yml

,

deployment.yml

, and other files, which are finally applied using

kubectl

for deployment management.