How to Manage Your Kubernetes Configurations with Kustomize?

How to Manage Your Kubernetes Configurations with Kustomize?

Kustomize is among the most valuable technologies inside Kubernetes, used for easing installation. Yes, it allows you to build a full Kubernetes service out of separate parts without altering their YAML configuration settings.

Here, you’ll get to know about kustomize and see how it functions with a basic WordPress installation. Moreover, you will explore how to use kustomize with kubectl, and the advantages of kutomize for large-scale operations. What is or isn’t correct is no longer relevant, as kustomize capability is now a standard component of the kubectl binary.

The Purpose behind kustomize

Kustomize is inspired by Helms in many ways, including the need to give application setup but with the opportunity to adapt the configuration to fit a specific purpose or environment. It aims to offer this for both bespoke and commercial off-the-shelf (COTS) applications.

The approach varies from Helm’s in that it insists on using YAML for customization settings instead of an obscure templating dialect. It’s safe to assume that DevOps professionals who deal with Kubernetes are already aware of the API service and YAML syntax demanded to define them. At least in principle, familiarity facilities painless adoption.

Kutomize may add a common field to a variety of resources, such as a label or annotation, change the setting of the current field, for instance, a Deployment’s amount of copies, and partly patch resources supplied as a “base” configuration. It also constructs configMap and secret resource settings from their canonical resource definitions.

What does Kustomize function?

Kustomize Is indeed a Kubernetes item configuration controller with the command-line interface. From version 1.14, it has been linked with kubectl, allowing you to perform declarative modifications to your setups without having to alter the templates. You can, for illustration, mix elements for several sources, preserving your adaptations or customizations., even as the matter could be – in version control systems, and develop overlays for certain scenarios.

Kutomize makes this possible by allowing you to create a document that binds it all together, or by including “overwhelms” for particular settings.

Following the below given steps to explore more;

Step 1: Deploy apps without kustomize

You would first launch your application in a much conventional fashion before using kustomize. Inside this Scenario, you will use NgnixI to serve a development edition of Sammy-app, a dynamic web service. Your site contents will be stored as information in a ConfigMap that will be mounted on a Pod in a deployment. All of them will necessitate the creation of a distinct YAML file, which you will do immediately.

Create a folder for your program and each of the configuration files initially;

mkdir ~/sammy-app && cd ~/sammy-app

All of the instructions in the guide will run from here.

In the home directory, create a new folder. You have given it the name sammy-app plus saved some HTML website content in information. Your file should be saved and closed.

Now make a new file named deployment.yml and enter it.

nano deployment.yml

Add the following;

apiVersion: apps/v1

kind: Deployment

metadata:

name: sammy-app

namespace: default

labels:

app: sammy-app

spec:

replicas: 1

selector:

matchLabels:

app: sammy-app

template:

metadata:

labels:

app: sammy-app

spec:

containers:

– name: server

image: nginx:1.17

volumeMounts:

– name: sammy-app

mountPath: /usr/share/nginx/html

ports:

– containerPort: 80

protocol: TCP

resources:

requests:

cpu: 100m

memory: “128M”

limits:

cpu: 100m

memory: “256M”

env:

– name: LOG_LEVEL

value: “DEBUG”

volumes:

– name: sammy-app

configMap:

name: sammy-app

items:

– key: body

path: index.html

This standard adds a new deploy item to the system. The title and label of sammy-app are added, the quantity of replicas is set at 1, and also the object is set to utilize the Ngnix edition 1.17 docker container.

Output

NAME READY STATUS RESTARTS AGE

sammy-app-56bbd86cc9-chs75 1/1 Running 0 8s

You are also changing the container’s address to 80, establishing CPU and memory demands and limits, and turning on DEBUG logging.

Even when your pods are up and operating, and are supported by a deployment, you are still unable to access the application. You should first make a service.

Make a 3rd YAML file named service.yml, then open it. Now you may start using the service on your Kubernetes cluster.

Take a few seconds before checking the status of the application using kubectl. Your external IP would be replaced by a unique IP address.

Cut/paste the IP address that depicts into your internet browser. You will notice your app’s DEVELOPMENT edition. Stop viewing your service, USe CTRL+C from the desktop.

Step 2: Use Kustomize for application deployment

You will install the same application inside the stage, although in the format kutomize anticipates rather than the normal kubernetes way.

You just have to add one file, customization.yml, to get this application deployable using kutomize.

nano kustomization.yml

That file will give the information to kubectl what service to handle when using the -k option, which tells kubectl to analyze thge kustomization file. Your file shoukd be saved and closed.

Now add the below command;

Resource:

– Configmap.yml

– Deployment.yml

– Service.yml

Save and exit it.

Next, when you re-deploy, remove the kubernetes service you created in step 1.

kubectl delete deployment/sammy-app service/sammy-app configmap/sammy-app

And then re-deploy them, this time using Kustomize.

kubectl apply -k .

The ConfigMap, Deploy, and Service are all created as a result of this. Verify your deployment with the get pods function.

kubectl get pods -l app=sammy-app

In the READY column, you will find a one pod containing your program executing and 1/1 containers. Restart the get process command immediately. Your service would additionally have a publicly available EXTERNAL-IP.

kubectl get services -l app=sammy-app

Step 3: Kustomize for monitoring application variability

While engaging with many resource types, particularly if there are minor changes across environments, application servers for Kubernetes resources can quickly become bloated just as the development versus production. Instead of having a deployment.yml, you may have deployment-development.yml plus deployment-production.yml.

The Scenario may be the same for each of your additional services. Consider what would happen if the latest version of the Nginx Docker image was published and you wanted to use it right away. Perhaps you want to proceed after testing the new edition in deployment-development.yml, but you neglect to update deployment-production.yml also with the new edition. Suddenly, the edition of Nginx you are using in development differs from the edition used in output. Small setup issues like these might cause your application to crash often.

Their administrative challenges can be substantially simplified using kustomize. Keep in mind that you currently possess a filesystem containing your Kubernetes configuration settings and customization.yml file.

sammy-app/

── configmap.yml

── deployment.yml

── kustomization.yml

── service.yml

The file would define the overlay’s basis, and the patching technique kubernetes will employ. To refresh the CongiMap and deploy resources, you can use a strategic-merge-stype fix in this case.

The file should be saved and closed.

At last, under the overlays.production.directory, create a new deployment.yml and configmap.yml files.

Now you are ready to use your base setup to deploy. Uninstall the current resource immediately. Deploy the kubernetes basic setup. Make sure that deployment is in proper condition.

Just one EXTERNAL-IP of the service, you will find the anticipated base setup, with the development versions showing. Now, you have to put the production setup into action. Examine your deployment once again. Just EXTERNAL-IP of the service, you will get the expected production setup, with the production model displayed.

In the production arrangement, you will see three Pods rather than one. Tool, you can check the deployment resources to see if the less visible modifications have gone into effect.

To see the production edition of your website, go to your external-ip in a browser. Kustomize is increasingly being used to control application variance. Returning to one of your initial issues, if you now wish to update the Nginx image edition, all you have to do is alter deployment.yml in the foundation, and all your layers that utilize that foundation will also receive the update via Kustomize. This streamlines your development process, enhances readability, and lowers the risk of mistakes.

What are the advantages of adopting kustomize?

Now you must have ensured about every detail of kustomize’s main advantages, that incorporates;

1. Declarative template

Kubernetes and Kustomize both employ a declarative method to system configuration.

2. Consolidation of codebases which is easy to follow

Monitoring and administration are simplified by applying chosen patches via a centralized file that may be stored under version controls.

3. Using kubectl for integration

There have been no new dependencies or prerequisites to bother about because Kustomize is already included in the basic Kubernetes toolset.

Conclusion

In a nutshell, with the above given steps, you must have created a web app or deployed that to kubernetes. Afterward, you utilize kustomize to make managing your application’s setup for various contexts a lot easier. You have created a layer model out of a collection of identical YAML files.

It will definitely assist you to avoid mistakes in manual setups. And will make your work more precise and manageable. Meanwhile, This is only a small part of what kustomize has to offer in Kubernetes.