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:

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

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:

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

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.

# 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/*

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.