Mastering Kubernetes with Kustomize: A Beginner's Guide to Customizing Your Deployments

Mastering Kubernetes with Kustomize: A Beginner's Guide to Customizing Your Deployments #k8s #devops
Github Repo used : github.com/Roh...
Timestamps:
Theory : 00:00
Practical :
Kustomize in Kubernetes: Understanding Bases and Overlays
Kustomize is a configuration management tool that allows you to customize Kubernetes resources without modifying the underlying YAML files. It works by overlaying configurations on top of base resource files, making it easier to manage different environments (e.g., development, staging, production) with minimal duplication of code.
Bases
Definition: A base is a set of Kubernetes resource files (like Deployments, Services, ConfigMaps, etc.) that define a common configuration for your application. Bases are typically environment-agnostic and contain the core logic or structure of your Kubernetes resources.
Purpose: Bases serve as the foundation for your Kubernetes deployments. They are reusable across multiple environments, providing a consistent starting point that can be tailored through overlays.
Example: A base might include a deployment.yaml file that defines your application's deployment configuration, a service.yaml file for the service definition, and other essential resources.
Overlays
Definition: An overlay is a set of modifications or transformations applied on top of a base to customize the configuration for a specific environment or use case.
Purpose: Overlays allow you to adjust the base configuration for different environments (e.g., changing replica counts, modifying image tags, or adding environment-specific labels). This ensures that each environment can have a tailored setup without altering the base files.
Types of Overlays:
Environment Overlays: Customizations for specific environments like dev, staging, or prod.
Feature Overlays: Modifications for specific features or tests, such as enabling a feature flag or running a canary deployment.
Example: An overlay for the dev environment might reduce the replica count in the deployment.yaml, change the image tag to a development build, or add labels and annotations relevant to development.
How It Works
Base Creation: First, you define the base configuration, which includes all the standard resources needed for your application. This configuration is stored in a separate directory.
Overlay Creation: Next, you create overlays that specify the changes needed for different environments. These overlays reference the base configuration and apply patches or transformations as required.
Applying Configurations: When deploying, you apply the overlay for the desired environment. Kustomize merges the base configuration with the overlay, generating the final YAML files that Kubernetes will apply.
Benefits of Kustomize
Separation of Concerns: By separating base configurations from environment-specific overlays, Kustomize promotes cleaner, more maintainable code.
Reusability: Bases can be reused across multiple environments or applications, reducing redundancy.
Flexibility: Overlays provide flexibility to adapt the base configuration for various scenarios without duplicating YAML files.
Kustomize is now built into kubectl, making it a powerful tool for anyone looking to manage Kubernetes resources more efficiently and consistently across multiple environments.
Follow my mentors too :@PavanElthepu @MPrashant @GouravSharma @cloudwithraj @AntonPutra @AbhishekVeeramalla @kubesimplify @kshindi @DevOpsJourney
Tags : #prometheus #secrets #docker #k8s #kubernetes #cncf #rbac #serverless #grafana #autoscaling #deployment #opensource #devops #grafana #vault #terraform #kustomize
#base #overlays

[@Fayaz-Rehman]

Nice - good job.

[@SandeepDash-sv6ql]

Please make a session on vpa installation on kubeadm, efk setup for log consolidation and also for how to increase pod capacity on each node which is default 110.
Please create videos like this based on realtime scenarios and requirements...

[@softwareengineer5764]

If you want to increase the pods limit, then you can do it by passing the required pod limit by passing it to the field max-pods in the Kubernetes configuration file.
$KUBELET_EXTRA_ARGS - max-pods=245

[@SandeepDash-sv6ql]

@@softwareengineer5764 yes, thanks... I know that, but how to do the same if your requirement is more ? Something like if you have sufficient resources on On-Premises server and you want to increase pod limit even above 500. How to do that ? Which CNI will be perfect here (Cilium or Calico) to configure IP POOL management for without confliction on Pod creation or deletions if you are creating above 500 pods on same node ?