You know how Kubernetes decide to find which Pods should be evicted if node resource is not enough or is running out? In this article, we’ll talk about this and introduce Kubernetes Quality of Service classes related to this topic. What is Node Pressure? Node pressure is a term that explains the worker node’s…

As you know, recently, Kubernetes changed its main repository from k8s.gcr.io to registry.k8s.io, meaning you should update your manifests as soon as possible. In this note, I tell you how you can find running Pods using the legacy Kubernetes image registry. https://kubernetes.io/blog/2023/03/10/image-registry-redirect The following command list all running Pods in…

What really is dnsPolicy in Pod spec, and when should we change it? By setting the dnsPolicy option in Pod spec, you define how DNS requests should be resolved. If you want to resolve DNS requests with just the internal DNS server, or you want to use the internal DNS…

Long time no see! After a long time, I got a chance to release and continue the complete Jenkins tutorial. In this article, we will learn how to use Git in our pipelines. Using Git is a most important topic in CI/CD pipelines as we store everything in Git, our…

In access-limited clusters where you don’t have access to cluster resources, you may need worker nodes’ info like worker node name, node IP address, etc. You can’t run kubectl get nodes in such clusters because the cluster admin has restricted your access to only particular namespaces and namespaced resources. This trick is for you if you are blocked in such a situation. First, you must run the following DaemonSet to ensure you have a Pod in every worker node to be able to find worker nodes’ info.

Do you want to know which images are downloaded and available on your worker nodes? If yes, you need to run the following command. kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{range .status.images[*]}{"\t"}{.names[0]}{"\n"}{end}{end}' This command list all Kubernetes nodes and their available images.

In some applications, the application configurations are set by default in the codebase (hard-coded) and if you want to override them, you can provide your override values through environment variables. Sometimes and for some configurations, it doesn’t matter if the override values exist. However, you want to make sure the…

Sometimes you want to create configs/secrets for your applications, and you want to make sure when configs/secrets got created, nobody can change or update them. For example, you want to setup cloud credentials, your git token, database credentials, etc., and prevent any changes after being created in the Kubernetes cluster. Kubernetes ConfigMap and Secret resources have a field called immutable which, if set to true, ensures that the data of ConfigMap/Secret cannot be updated after the resource is created.

In this article, I speak about the Terraform Providers and Resources. If you didn’t read the previous article, it’s time to read it before continuing this article. You can find all Terraform Tutorials and their examples in the following GitHub repository. GitHub - ssbostan/terraform-tutorial: The completest Terraform tutorial, reference, awesome… Stargaze if you find it useful. STAR STAR STAR. The repository of reference and examples of the Terraform tutorial…github.com