Wolkwacht is my personal corner of the internet, where I share what I learn and think about cloud technology, Kubernetes, security, and digital sovereignty. I’m Jurgen Allewijn, and I’m passionate about exploring where technology, control, and trust intersect. Away from the keyboard, I enjoy flying drones and capturing the world from a different perspective through aerial photography.
Transferring a Dapr-enabled application from local Kubernetes to AKS should be straightforward. The annotations, app ID, application port, sidecar API, and workload manifest stay familiar. The key difference is ownership: a temporary local setup transforms into a shared runtime that requires a version policy, availability plan, network access, identity strategy, and support structure. This post moves the sample from Installing Dapr on Kubernetes Locally with OrbStack to an existing AKS cluster. We will compare the open-source installation path with the AKS Dapr extension, install the extension, verify the control plane, and deploy the same NGINX workload. ...
To quickly grasp Dapr on Kubernetes, it’s best to start locally rather than with an AKS cluster. Local setup allows for rapid pod creation in seconds, minimizes the consequences of mistakes, and keeps all control-plane components easily accessible for inspection. In this post, we’ll demonstrate setting up OrbStack’s single-node Kubernetes cluster on macOS, installing Dapr in development mode, examining the creation process, deploying a simple web app with a sidecar, and accessing it via Dapr’s HTTP API. The same annotations and runtime model apply to AKS later, with only differences in the platform and installation approach. ...
Every distributed application gathers various plumbing components. One service requires retries and timeouts, another needs a message broker client, and a third must store some state, retrieve secrets, or discover other services. Over time, each team ends up with a unique set of client libraries, connection handling methods, telemetry, and failure behaviors. Dapr, the Distributed Application Runtime, provides a uniform API for the underlying infrastructure. Your application communicates with a local Dapr process via HTTP or gRPC. Dapr then interacts with services, the state store, the broker, the secret store, or other components on your application’s behalf. While the application retains control of its business logic, Dapr offers reusable capabilities for building distributed applications. ...
The real question is not whether to use the Azure Key Vault provider for the Secrets Store CSI Driver or the External Secrets Operator (ESO). Instead, it’s whether your workload should access secret data as mounted files or via native Kubernetes Secret objects. That choice influences application design, rotation, incident handling, RBAC, observability, Helm compatibility, and GitOps. In short: CSI offers a more secure default for applications that consume files; ESO provides a more practical platform default when Kubernetes-native compatibility is a priority. This decision involves both GitOps and security considerations. ...
Kubernetes is very good at reporting desired state. A Deployment can be available while its pods restart every few hours. A cluster can show green nodes while workloads have no disruption budgets, probes, resource limits, or network isolation. Dashboards show signals; they do not necessarily connect them into an operational judgment. That is the gap KubeBuddy tries to fill. The open-source KubeDeck project is a Go-based command-line scanner that connects through an existing Kubernetes context and evaluates cluster health, workloads, security, RBAC, networking, storage, and configuration. It can add provider-specific checks for AKS and GKE and emit terminal, HTML, JSON, and CSV output. There is no controller, Helm release, or long-running agent to install in the cluster. ...
Kubernetes has become so familiar that many teams don’t choose to adopt it anymore; they just start using it. When a new internal API appears, someone sets up an AKS cluster, and within weeks, the team manages node pools, upgrade channels, ingress, identity, policies, observability, and a backlog of Helm charts. None of these decisions are incorrect, but the issue is that the workload might never have required a Kubernetes platform in the first place. ...
Azure Kubernetes Service (AKS) removes most of the undifferentiated heavy lifting of running Kubernetes, but it does not remove your responsibility for securing what runs on top of it. Every week, new clusters go into production with permissive RBAC, public API servers, root-privileged containers, and no plan to stay current with CVEs. None of that is an AKS problem; it is an operating-model problem. This practical, opinionated guide walks through securing an AKS cluster from start to finish: identity, network, workload, supply chain, runtime security, and the often-overlooked process of maintaining security over time. ...
A cloud architect’s field notes on apple/container v1.2.0, for the devops engineers and application specialists who have to make the “what runs on our Macs” decision. A year ago I published Running Containers the Apple Way: A First Look into Apple Container on macOS. At the time, container was a WWDC 2025 curiosity: a Swift CLI with no stability guarantees and a limited list of things it could actually do. I was cautiously optimistic and noted, in effect, “watch this space.” ...
Introduction: Cost Is an Outcome of Scheduling Decisions Your AKS bill is calculated before Azure sends an invoice. Kubernetes translates pod specifications into resource requirements, including resource requests, affinity rules, topology constraints, DaemonSet overhead, and scaling limits, all of which impact the efficiency of pod placement on nodes. This post’s main point is clear: durable optimization involves enhancing the entire chain, from workload demand to pod replicas, schedulable capacity, VM allocation, and cost attribution. Reducing node count without understanding this chain does not save money; it simply shifts costs into latency, evictions, throttling, and extended recovery periods. ...
Running AI Workloads on Azure Kubernetes Service: From Platform Control to Model Serving Most teams begin their AI journey by using a managed model API. This approach works initially but can become problematic when costs become unpredictable at scale, data sovereignty or compliance issues prevent sending data to third-party endpoints, or the team needs a fine-tuned model or a custom inference runtime. At this stage, the focus shifts from simply consuming AI to actively operating it. ...