Something that I love is to be able to troubleshoot fast (or at least have the right tooling for it). Working in a Kubernetes environment, I often find myself needing to get pods environment variables and secrets either for debugging purposes or auditing. I wanted something that would give me everything I need fast and at a glance in my terminal.
In this blog post I’ll share the little script I created to achieve this and how to add it to your shell as a function.
Recently a new vulnerability in OpenSSH has been identified and the first question that popped into my mind was: How do I make sure my nodes are not affected by _this vulnerability?
In this blog post, I wanted to go over what the vulnerability is, how it can be exploited, explain how you can check if your Azure Kubernetes Service (AKS) is vulnerable to CVE-2024-6387 and what you can do about it, including different options for upgrading the VMSS image and how to choose between them.
A CNCF project, the Distributed Application Runtime (Dapr) provides APIs that simplify microservice connectivity. Whether your communication pattern is a service-to-service invocation or pub/sub messaging, Dapr helps you write resilient and secured microservices. Essentially, it provides a new way to build microservices by using the reusable blocks implemented as sidecars.
While Dapr is great as it is language agnostic and it solves some challenges that come with microservices and distributed systems, such as message broker integration, encryption etc, troubleshooting Dapr issues can be quite challenging. Dapr logs, especially the error messages, can be quite generic and sometimes do not provide enough information for you to understand what is going on.
The other day I was making changes to my helm charts and, after deploying my application, I noticed that one of my pods was stuck in a CreateContainerConfigError state. This is a pretty tricky error because it doesn’t give you any details on what the underlying issue could be.
What is the CreateContainerConfigError? # To understand this, let’s look at what happens at deployment time to give you an idea of the flow and what could go wrong at each step.
In today’s world, security is a top priority for any organization or at least it should be. With the rise of cloud computing, the number of security threats has increased exponentially.
So how do we keep up? Where do we start?
Microsoft has created a set of security benchmarks to give users a starting point for setting up their security configurations. The Microsoft cloud security benchmark (MCSB) is the successor of Azure Security Benchmark (ASB), which was rebranded in October 2022 (Currently in public preview).
When I started migrating to Kubernetes (K8s) I discovered that I can use Terraform for managing not only the infrastructure, but also I could define the K8s objects in it, but I also could use Helm to handle that. But what would be a good way to handle this?
In this post we will cover Terraform and Helm for managing Kubernetes clusters with some code snippets and an idea on how you can use them together to get you started.
This article applies to: Helm v3.8.0
Helm helps you manage Kubernetes applications â Helm Charts help you define, install, and upgrade even the most complex Kubernetes application. More details on Helm and the commands can be found in the official documentation.
Assuming you use Helm to handle your releases, you might end up in a case where the release will be stuck in a pending state and all subsequent releases will keep failing.
This article applies to Kubernetes v1.15 and above.
Kubernetes, also known as K8s, is an open-source system for automating the deployment, scaling, and management of containerized applications.
It groups containers that make up an application into logical units for easy management and discovery. But what if something happens to the container? In this case, you might need a quick and easy way to restart it.
Kubernetes Pods usually run until there is a new deployment that will replace them. Therefore, there is no straightforward way to restart a single pod.
In our current environment we have Kong as our Ingress controller in front of our applications.
We are also using the Kong CORS Plugin to enable browsers to make cross-origin requests to our application’s backend. The CORS plugin lets you configure the API gateway behavior to support Cross-Origin Resource Sharing (CORS). If you want to dig deeper into what CORS is, please check the CORS glossary link.
We also make use of helm charts to handle our deployment.
