Cronjob to restart a deployment

— ny_wk

Ever found yourself in a situation where your Kubernetes deployments need a periodic refresh? Maybe it's a memory leak slowly creeping up, an old cache that needs busting, or simply a requirement to ensure your application picks up new configurations without a full redeploy. Manually restarting deployments can be a tedious and error-prone task, especially in large clusters. This is where a Kubernetes CronJob to restart a deployment comes into play, offering a robust, automated solution to keep your applications fresh and performant. In this deep dive, we'll explore how to set up a powerful CronJob that can intelligently trigger a kubectl rollout restart for your deployments, ensuring stability and reducing operational overhead.

Automating routine maintenance tasks like restarting deployments is a cornerstone of efficient DevOps practices. A well-configured Kubernetes CronJob not only saves you precious time but also minimizes the risk of human error during critical operations. We'll walk through the entire process, from understanding the underlying components like ServiceAccounts and Role-Based Access Control (RBAC) to crafting the perfect CronJob definition and verifying its execution. Consider this your chai-time chat on making your Kubernetes cluster a bit smarter, a bit more self-healing, without you having to lift a finger every single time.

The "Why" Behind Automated Deployment Restarts in Kubernetes

In the dynamic world of cloud-native applications, even the most robust services can sometimes benefit from a fresh start. While Kubernetes is excellent at self-healing by replacing unhealthy pods, there are scenarios where a full deployment restart is not just beneficial, but necessary. Let's delve into the common reasons why you might want to automate a deployment restart, and how it translates into practical advantages for your system reliability.

Common Scenarios for Automated Restarts

• Memory Leaks or Resource Bloat: Over time, some applications might exhibit subtle memory leaks or accumulate excessive resources that aren't properly released. A periodic restart can effectively "clean the slate," bringing resource consumption back to baseline levels and preventing performance degradation or OOMKills. This is especially true for long-running services that don't gracefully handle resource management.
• Cache Invalidation or Data Staleness: Applications often rely on in-memory caches or connections to external systems. If these caches become stale or data integrity issues arise, a restart can force the application to re-initialize its state, fetching fresh data and clearing out any inconsistencies.
• Configuration Reloads: While many modern applications support hot-reloading configurations, some older or more complex systems might require a full restart to pick up new environment variables, mounted ConfigMaps, or Secret updates. Automating this ensures that configuration changes are applied consistently across all instances.
• Load Balancing Across Nodes: In certain situations, you might want to force your pods to reschedule across different nodes, perhaps after node maintenance, or to balance the load more evenly across your cluster. A restart prompts the Kubernetes scheduler to re-evaluate where pods should run, potentially leading to better resource utilization.
• Application "Freshness": Sometimes, it’s just about ensuring your application instances are regularly refreshed, like a good old machine reboot. This can help prevent unforeseen cumulative issues that might build up over extended uptime.

The Limitations of Manual Restarts

Picture this: it's 3 AM, and an alert for high memory usage on a critical service wakes you up. Your immediate thought is to restart the deployment. You log into your cluster, run kubectl rollout restart deployment/my-critical-app, and breathe a sigh of relief as resources stabilize. But what if this happens every few days? Manual intervention becomes a bottleneck, a source of toil, and prone to errors. You might forget to do it, pick the wrong namespace, or even restart the wrong application. This is where automation shines. A Kubernetes CronJob to restart a deployment takes this manual burden off your shoulders, executing the command precisely when needed, without human intervention.

Introducing kubectl rollout restart

Before we dive into the CronJob itself, let's briefly understand the star of the show: kubectl rollout restart. This command is specifically designed for gracefully restarting deployments. When you execute it, Kubernetes internally updates the deployment's pod template by adding or changing an annotation (usually kubectl.kubernetes.io/restartedAt with a timestamp). This small change is enough to trigger a rolling update, meaning Kubernetes will progressively terminate old pods and bring up new ones, ensuring zero downtime for your application if you have sufficient replicas and readiness probes configured. It's much safer and more elegant than deleting pods manually, which can cause service interruptions.

By leveraging this powerful command within a scheduled CronJob, we achieve a robust, automated, and non-disruptive way to manage the lifecycle of our applications in Kubernetes.

Demystifying the Kubernetes CronJob: A Step-by-Step Guide

Now that we understand the 'why,' let's get into the 'how.' Creating a Kubernetes CronJob to restart a deployment involves several moving parts: a ServiceAccount for permissions, an RBAC Role and RoleBinding to grant those permissions, and finally, the CronJob definition itself. We'll break down each component, explaining its purpose and configuration, just like we’re dissecting a new feature over a cup of strong chai.

For our example, we'll be working with two primary YAML files: nginx_deployment.yaml for the application we want to restart, and cron-job.yaml which defines all the necessary components for our automated restart mechanism.

The Target: Our Nginx Deployment (nginx_deployment.yaml)

First things first, we need an application to restart. For this demonstration, we'll use a simple Nginx deployment. This YAML defines a standard Nginx web server with three replicas. Nothing too fancy here, but it serves as a perfect target for our CronJob.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Explanation:

• apiVersion: apps/v1 and kind: Deployment: Standard Kubernetes Deployment resource.
• metadata.name: nginx-deployment: The name of our deployment, which our CronJob will target.
• spec.replicas: 3: We want three instances of our Nginx application.
• spec.selector and spec.template.metadata.labels: Define how the deployment finds and manages its pods.
• spec.template.spec.containers: Defines the container specifications, in this case, an nginx:1.14.2 image listening on port 80.

This deployment is what we'll be restarting periodically. Now, let's move on to the core components of our CronJob setup.

The Restart Mechanism: Unpacking cron-job.yaml

The cron-job.yaml is where all the magic happens. It's a multi-document YAML file, defining a ServiceAccount, a Role, a RoleBinding, and the CronJob itself. Each component is crucial for securely and effectively executing our desired restart command.

1. The ServiceAccount: Who is doing the work?

Every action in Kubernetes is performed by someone or something. When a Pod (or in our case, a Job created by a CronJob) needs to interact with the Kubernetes API, it does so using a ServiceAccount. This is its identity within the cluster. By default, pods get a default ServiceAccount, but it's best practice to create a dedicated one with minimal permissions.

---
kind: ServiceAccount
apiVersion: v1
metadata:
  name: restart-nginx-deployment
  namespace: test

Explanation:

• kind: ServiceAccount: Declares this resource as a ServiceAccount.
• metadata.name: restart-nginx-deployment: A descriptive name for our ServiceAccount.
• metadata.namespace: test: This ServiceAccount lives in the test namespace. Important: All related RBAC objects and the CronJob itself must be in the same namespace as the ServiceAccount and the target deployment for this setup to work correctly.

2. The Role: What can they do?

A Role defines a set of permissions within a specific namespace. We need to grant our ServiceAccount the ability to interact with deployments. Specifically, to perform a kubectl rollout restart, the ServiceAccount needs get and patch permissions on deployments.

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: restart-nginx-deployment
  namespace: test
rules:
  - apiGroups: ["apps"] # Deployments belong to the "apps" API group
    resources: ["deployments"]
    resourceNames: ["nginx-deployment"] # Restrict to only this specific deployment
    verbs: ["get", "patch"]

Explanation:

• kind: Role: Declares this resource as a Role.
• metadata.name and metadata.namespace: Name and namespace for the Role, matching the ServiceAccount.
• rules: This is where the permissions are defined.
  • apiGroups: ["apps"]: Specifies the API group for deployments. Older versions might have used "extensions", but "apps" is the current standard.
  • resources: ["deployments"]: Specifies the type of resource the permissions apply to.
  • resourceNames: ["nginx-deployment"]: This is crucial for security! We are using the principle of least privilege. This ensures that our ServiceAccount can *only* interact with the nginx-deployment and no other deployments in the namespace. Bilkul pakka, we don't want it messing with production deployments by mistake, right?
  • verbs: ["get", "patch"]: These are the minimum permissions required. get is needed to read the deployment's current state, and patch is needed to modify its annotations to trigger the restart.

3. The RoleBinding: Connecting the dots

A RoleBinding connects a Role (the permissions) to a Subject (which can be a User, Group, or ServiceAccount). This is how our restart-nginx-deployment ServiceAccount gets the permissions defined in our Role.

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: restart-nginx-deployment
  namespace: test
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: restart-nginx-deployment
subjects:
  - kind: ServiceAccount
    name: restart-nginx-deployment
    namespace: test

Explanation:

• kind: RoleBinding: Declares this resource as a RoleBinding.
• metadata.name and metadata.namespace: Name and namespace for the RoleBinding, matching the ServiceAccount and Role.
• roleRef: References the Role we just created. It needs the apiGroup, kind, and name of the Role.
• subjects: Specifies who gets the permissions. Here, it's our restart-nginx-deployment ServiceAccount.

4. The CronJob: The Scheduler and Executor

Finally, the star of the show! The CronJob defines a scheduled task. It will create Job objects on a recurring schedule, and these Jobs will in turn create Pods that execute our desired command.

---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: restart-nginx-deployment
  namespace: test
spec:
  concurrencyPolicy: Forbid # Do not run concurrently!
  schedule: '*/5 * * * *' # At every 5th minute
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 600
      template:
        spec:
          serviceAccountName: restart-nginx-deployment # Run under our dedicated SA
          restartPolicy: Never # Important for Jobs!
          containers:
          - name: kubectl
            image: raspbernetes/kubectl # Image with kubectl pre-installed
            command:
            - 'kubectl'
            - 'rollout'
            - 'restart'
            - 'deployment/nginx-deployment'

Explanation:

• apiVersion: batch/v1beta1 and kind: CronJob: Defines a CronJob resource. While batch/v1 is the current stable API, v1beta1 is still commonly used and functional. If your cluster supports it, consider using batch/v1.
• metadata.name and metadata.namespace: Name and namespace for the CronJob.
• spec: Contains the CronJob's core configuration.
  • concurrencyPolicy: Forbid: This is an important setting. It means that if a previous Job created by this CronJob is still running when a new scheduled time arrives, the new Job will be skipped. Other options include Allow (run concurrently) and Replace (cancel the current running Job and replace it with the new one). For a restart operation, Forbid is usually the safest choice to avoid multiple simultaneous restarts.
  • schedule: '*/5 * * * *': This is the standard cron format. This specific schedule means the Job will run "at every 5th minute." So, at 0, 5, 10, 15... minutes past the hour. You can adjust this to suit your needs (e.g., 0 0 * * * for daily at midnight, or 0 */6 * * * for every 6 hours).
  • jobTemplate.spec: This defines the template for the Job that the CronJob will create.
    • backoffLimit: 2: If the Job fails, it will retry up to 2 times. This helps with transient issues.
    • activeDeadlineSeconds: 600: The maximum time, in seconds, the Job is allowed to run. If it exceeds this, it will be terminated. 10 minutes (600 seconds) should be ample for a kubectl rollout restart.
    • template.spec: This is the Pod template for the Job.
      • serviceAccountName: restart-nginx-deployment: This tells the Job's Pod to use the ServiceAccount we created, granting it the necessary RBAC permissions.
      • restartPolicy: Never: For Jobs, this is almost always set to Never. It means that if the container exits, the Pod will not be restarted. The Job controller manages retries based on backoffLimit. This is different from the restartPolicy for containers *within* a Deployment's Pods.
      • containers: The actual container that will execute our command.
        • name: kubectl: A descriptive name for the container.
        • image: raspbernetes/kubectl: We need an image that has the kubectl binary installed. raspbernetes/kubectl is a common choice. Other options include bitnami/kubectl or you could even bake your own.
        • command: This is the array of strings that forms the command to be executed inside the container.
          • - 'kubectl'
          • - 'rollout'
          • - 'restart'
          • - 'deployment/nginx-deployment': This is our target command, instructing kubectl to perform a rolling restart on the nginx-deployment.

Phew! That was a lot, yaar. But understanding each part is crucial for building reliable and secure automation in Kubernetes. Now that we have our YAMLs ready, let's talk about putting them into action.

Implementation and Verification: Getting Your CronJob to Work

Alright, we've designed our beautiful YAML manifests. It's time to bring them to life in our Kubernetes cluster. The implementation process is straightforward, but verification is key to ensure everything is working as expected. Let's get our hands dirty with some kubectl commands.

Prerequisites

Before you begin, ensure you have:

• Access to a Kubernetes cluster.
• kubectl installed and configured to communicate with your cluster.
• The nginx_deployment.yaml and cron-job.yaml files saved locally.

Deployment Steps

First, we'll set our context and namespace. It's good practice to explicitly define the namespace where you're working, especially when dealing with RBAC and CronJobs, to prevent accidental deployments to the wrong place. The source video uses `metricgaming-test` in commands and `test` in YAML; we'll stick to `test` for consistency in our examples.

# 1. Set the current kubectl context to the desired namespace
kubectl config set-context --current --namespace=test

# If the namespace doesn't exist, create it first
# kubectl create namespace test

Now, let's deploy our application and then the CronJob components:

# 2. Deploy the Nginx application
echo "Deploying nginx-deployment..."
kubectl apply -f nginx_deployment.yaml
# Expected output: deployment.apps/nginx-deployment created

# 3. Deploy the CronJob, ServiceAccount, Role, and RoleBinding
echo "Deploying CronJob components..."
kubectl apply -f cron-job.yaml
# Expected output:
# serviceaccount/restart-nginx-deployment created
# role.rbac.authorization.k8s.io/restart-nginx-deployment created
# rolebinding.rbac.authorization.k8s.io/restart-nginx-deployment created
# cronjob.batch/restart-nginx-deployment created

Once you run these commands, all your resources should be created in the `test` namespace.

Verification: Did it work, boss?

Deploying is only half the battle; the real test is seeing if it actually works. We need to verify that the CronJob is scheduled, creates Jobs, and those Jobs successfully trigger the deployment restart.

1. Check the CronJob status

Verify that your CronJob is created and scheduled correctly:

kubectl get cronjob -n test

You should see output similar to this:

NAME                       SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
restart-nginx-deployment   */5 * * * *   False     0        <none>          1m

Initially, LAST SCHEDULE might be <none>, indicating it hasn't run yet. Within 5 minutes (based on our schedule), you should see this update.

2. Observe Job and Pod creation

When the CronJob runs, it creates a Job resource, which in turn creates a Pod. Keep an eye on these:

# Watch for Jobs created by the CronJob
kubectl get jobs -n test --watch

# Watch for Pods created by the Jobs
kubectl get pods -n test --watch

After the first scheduled run (e.g., at the 5-minute mark), you should see a Job appear, followed by a Pod for that Job. The Job Pod will run the kubectl rollout restart command and then complete. The Job status should eventually change to `Completed`.

3. Verify the Deployment Restart

This is the ultimate check. A successful kubectl rollout restart updates an annotation on the deployment's pod template, which triggers a new rollout. We can check the deployment's rollout history or its annotations to confirm this.

# Check the rollout history (to see multiple revisions)
kubectl rollout history deployment/nginx-deployment -n test

# Check the deployment description for the 'restartedAt' annotation
kubectl describe deployment nginx-deployment -n test | grep -i "restartedAt"

Initially, you'll see one revision. After the CronJob successfully runs, you should see a new revision appear in the history. The kubectl describe command should show an annotation similar to kubectl.kubernetes.io/restartedAt: "2023-10-27T10:30:00Z" (the timestamp will vary). Each restart will update this timestamp, triggering a new rolling update. You can also watch the pods of your Nginx deployment; you'll see new pods being created and old ones terminating.

# Watch the Nginx deployment pods
kubectl get pods -l app=nginx -n test --watch

You'll notice pods with new suffix hashes being created and old ones gracefully terminating as the rollout progresses. This confirms your Kubernetes CronJob to restart a deployment is working like a charm!

Rollback and Cleanup

If you need to remove these resources, perhaps for testing different configurations or if this automation is no longer needed, you can delete them:

echo "Deleting CronJob components..."
kubectl delete -f cron-job.yaml

echo "Deleting nginx-deployment..."
kubectl delete -f nginx_deployment.yaml

This will remove the ServiceAccount, Role, RoleBinding, CronJob, and the Nginx deployment from your cluster.

Best Practices, Gotchas, and Advanced Considerations

Automating deployment restarts with Kubernetes CronJobs is powerful, but like any powerful tool, it comes with responsibilities. A good DevOps engineer always thinks about security, robustness, and potential pitfalls. Let's discuss some best practices and advanced considerations to make your setup production-ready.

1. Namespace Consistency: A Common Pitfall

One of the most frequent issues developers face is a mismatch in namespaces. As observed in the source material, the YAML defined namespace: test, while some `kubectl` commands referred to `namespace: metricgaming-test`. This kind of inconsistency will lead to your CronJob failing to find its ServiceAccount, or the ServiceAccount failing to find the deployment it's supposed to restart. Always ensure that the ServiceAccount, Role, RoleBinding, CronJob, and the target Deployment are all defined and operating within the same Kubernetes namespace. If your deployment is in `prod-app`, then your CronJob and its associated RBAC must also be configured for `prod-app`.

2. Security First: Least Privilege RBAC

The RBAC setup in our `cron-job.yaml` followed the principle of least privilege by using resourceNames: ["nginx-deployment"]. This is absolutely critical. Imagine if your CronJob had permissions to restart *any* deployment in the namespace or, worse, the entire cluster! A misconfiguration in the Cron schedule or a bug in the `kubectl` image could lead to widespread outages. Always ask: what is the absolute minimum permission this automated process needs to function? And grant precisely that.

For more complex scenarios where you might need to restart multiple deployments or deployments matching a label, you would broaden the resources but still be cautious. For example, to restart all deployments with label app: frontend:

rules:
  - apiGroups: ["apps"]
    resources: ["deployments/rollback"] # The specific subresource for rollout undo
    verbs: ["create"] # Rollback specific verb
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "patch", "list"] # 'list' if you need to find deployments by label

This is a more advanced pattern and should be used with extra care. For a simple targeted restart, resourceNames is the way to go.

3. Pinning Image Versions for Stability

In our CronJob, we used image: raspbernetes/kubectl. While this works, specifying a particular tag (e.g., raspbernetes/kubectl:1.27.3) is a better practice. Using `:latest` can lead to unexpected behavior if the image maintainer introduces breaking changes. Pinning ensures that your CronJob's environment remains stable and predictable across runs.

4. Robust Error Handling: backoffLimit and activeDeadlineSeconds

These fields in the `jobTemplate` are your safety net:

• backoffLimit: Defines how many times a Job will be retried if its Pod fails. A value of 2 means it will try up to 3 times in total (initial run + 2 retries). This helps recover from transient network issues or temporary API server unavailability.
• activeDeadlineSeconds: Sets an upper time limit for the Job. If the Job takes longer than this, Kubernetes will terminate it, preventing runaway processes. This is especially useful if, for some reason, the kubectl rollout restart command hangs indefinitely.

Always configure these values thoughtfully based on the expected duration and criticality of your job.

5. Monitoring and Alerting

Even automated processes need oversight. Integrate monitoring for your CronJobs:

• Job Failures: Alert if a Job created by your CronJob fails (e.g., its Pod exits with a non-zero status). This could indicate issues with RBAC, the target deployment, or the kubectl command itself.
• Skipped Jobs: If you use concurrencyPolicy: Forbid, monitor if Jobs are being consistently skipped. This might mean the previous Job is taking too long to complete, indicating a problem.
• Deployment Rollout Status: After the CronJob triggers a restart, monitor the target deployment's rollout status. Ensure it completes successfully and new pods are healthy.

6. Alternatives and When to Use Them

While CronJobs are excellent for scheduled tasks, they aren't the only way to manage deployments:

• ArgoCD/FluxCD Sync Waves: For GitOps users, tools like ArgoCD allow defining "sync waves" to control the order of resource deployment. You can potentially use pre/post-sync hooks or custom health checks to trigger restarts as part of a larger GitOps workflow, often a more integrated approach for application lifecycle management.
• Custom Operators/Controllers: For highly specific and complex restart logic (e.g., restarting based on external metrics or specific application states), you might consider developing a custom Kubernetes Operator. This gives you maximum flexibility but requires significant development effort.
• External Schedulers: Tools like Jenkins, GitLab CI, or other external schedulers can also trigger kubectl commands. However, keeping the scheduling logic within Kubernetes (via CronJobs) is often simpler and more "native" for tasks that are purely cluster-internal.

For a simple, time-based, automated restart, a Kubernetes CronJob is often the most straightforward and efficient solution. Yaar, sometimes the simplest solution is the best one!

7. What if the Deployment Doesn't Exist?

If your CronJob runs and the nginx-deployment doesn't exist (perhaps it was deleted or never created), the kubectl rollout restart command will fail. The Job Pod will exit with an error, and the Job will be marked as failed (potentially retrying based on backoffLimit). Monitoring for these Job failures is essential to catch such scenarios.

By keeping these considerations in mind, you can build a robust, secure, and reliable system for automating your Kubernetes deployment restarts, reducing manual toil and enhancing the overall stability of your applications. It’s all about working smarter, not harder!

Key Takeaways

• A Kubernetes CronJob to restart a deployment is a powerful automation tool for maintaining application health and freshness.
• It leverages kubectl rollout restart to trigger a graceful, zero-downtime rolling update of your deployment.
• The setup requires a dedicated ServiceAccount, a precise RBAC Role with get and patch permissions on the target deployment, and a RoleBinding to link them.
• The CronJob's schedule defines the recurrence using standard cron syntax, and concurrencyPolicy: Forbid is crucial to prevent simultaneous restarts.
• Always ensure namespace consistency across all related YAML definitions (ServiceAccount, Role, RoleBinding, CronJob, and the target Deployment).
• Prioritize security by applying the principle of least privilege, specifically using resourceNames in your Role definitions.
• Configure backoffLimit and activeDeadlineSeconds in your Job template for robust error handling and to prevent runaway jobs.
• Implement comprehensive monitoring and alerting for CronJob failures and successful deployment rollouts to maintain visibility.

Frequently Asked Questions

How can I restart multiple deployments with a single Kubernetes CronJob?

To restart multiple deployments, you have a few options. The simplest is to create multiple containers within the CronJob's Pod, each executing kubectl rollout restart deployment/<deployment-name> for a different deployment. Alternatively, you could modify the RBAC Role to include permissions for multiple resourceNames or use broader selectors (like labels) if you trust the automation sufficiently, and then use scripting (e.g., a custom script in the container image) to iterate through deployments that match specific criteria and restart them.

How can I make the CronJob run immediately for testing purposes?

To test your CronJob setup without waiting for its schedule, you can manually create a Job resource from the CronJob's template. Use the command: kubectl create job --from=cronjob/restart-nginx-deployment <job-name> -n test. Replace `<job-name>` with a unique name for your test job. This will instantly create a Job that runs the specified command, allowing for quick verification.

Is it safe to restart a Kubernetes deployment frequently (e.g., every minute)?

While technically possible, restarting a deployment every minute (* * * * *) is generally not recommended unless you have a very specific, well-understood requirement for it. Each restart triggers a rolling update, meaning old pods are terminated and new ones are brought up. This process consumes cluster resources, generates logs, and puts churn on your application. For most memory leak or cache invalidation issues, a less frequent schedule (e.g., hourly, daily, or every few hours) is usually sufficient and less disruptive. Always monitor your application's behavior closely after implementing such frequent restarts.

What happens if the kubectl image in the CronJob is outdated or unavailable?

If the specified kubectl image (e.g., raspbernetes/kubectl) is outdated, the kubectl rollout restart command might fail or behave unexpectedly if there are API version incompatibilities or command syntax changes. If the image is completely unavailable (e.g., registry down, image deleted), the CronJob's Job Pods will enter a `ImagePullBackOff` or `ErrImagePull` state and will fail to run, preventing the restart command from executing. Always use a stable, version-pinned image and ensure your cluster has access to its registry.

Implementing automated processes like a Kubernetes CronJob to restart a deployment is a critical skill for any DevOps engineer looking to build resilient and self-managing systems. It’s all about understanding the building blocks and assembling them securely and efficiently.

Want to see this in action and get a visual walkthrough? Don't forget to watch the original video on this topic. And while you're there, make sure to subscribe to @explorenystream for more insightful DevOps content and practical Kubernetes tutorials!