For years, the answer to “how do we get traffic into the cluster?” was the same in almost every team I worked with: install ingress-nginx, add a few annotations, done. It was the default in tutorials, the default in Helm charts, and on AKS it was even the engine behind the application routing add-on. ...
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. ...
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. ...
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. ...
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. ...
Optimizing Azure Container Apps Costs: Scaling to Zero, Workload Profiles, and FinOps Azure Container Apps enables teams to deploy APIs, background processors, scheduled jobs, and event-driven services without directly managing Kubernetes infrastructure. However, this convenience does not automatically ensure cost optimization. Container Apps costs depend on application behavior: the number of replicas, their active duration, the workload profile hosting them, and the telemetry or network traffic they produce. An efficient setup for an unpredictable queue worker might be wasteful for a constantly busy API, and vice versa. ...
Part 1 introduced AppNet, while Part 2 demonstrated its use in zero-trust and multi-cluster patterns. This concluding section explores a shared AI gateway, the operational signals derived from the mesh, and the architectural tradeoffs that influence whether AppNet should be integrated into your platform. Series navigation Part 1: What AppNet is and how to get started Part 2: Zero-trust and multi-cluster patterns Part 3: AI gateway, observability and production fit Example three: a shared AI gateway that rate-limits by application AI Gateway with Per-Application Token Rate Limiting] ...
In Part 1, we discussed the AppNet architecture, setup process, and waypoint model. This second part shifts focus from mechanics to platform patterns: it covers enforcing service-to-service authorization for a payments platform, and then using AppNet across AKS clusters for active-active regional architectures. Series navigation Part 1: What AppNet is and how to get started Part 2: Zero-trust and multi-cluster patterns Part 3: AI gateway, observability and production fit Example one: Zero-trust authorization for a payments platform Zero-Trust Authorization — Payments Namespace ...
Azure Kubernetes Application Network, Part 1: What AppNet Is and How to Get Started The space between ‘we have ingress’ and ‘we run a full service mesh with sidecars on every pod’ has always been a challenging middle ground. Platform teams want encrypted east-west traffic, identity-based authorization, and good observability, but aim to avoid the CPU, memory, startup delay, and on-call burden associated with a sidecar on each workload. Security architects look for a zero-trust framework they can verify during audits, not just visual diagrams. Application developers need routing, retries, and traffic shifting without needing to understand Envoy’s internals. Meanwhile, platform engineers prefer these features as first-class Azure resources rather than managing complex Helm charts that require constant oversight. ...