#kubernetes

Prioritizing Recent Messages with Go Channels

Khi xây dựng hệ thống chỉ quan tâm giá trị mới nhất, cơ chế chặn mặc định của Go channels trở thành hạn chế. Bài viết giới thiệu hai cách giải quyết: gửi không chặn bằng select/default (bỏ qua giá trị khi buffer đầy, an toàn cho nhiều producers) và xả buffer trước khi gửi (đảm bảo consumer nhận dữ liệu mới nhất, nhưng yêu cầu single producer). Các ví dụ kèm biểu đồ ASCII minh họa ưu nhược điểm của từng phương pháp.

Một lập trình viên nên đọc bài này để hiểu cách xử lý hiệu quả các kênh Go khi chỉ cần lưu giữ thông tin mới nhất, tránh rủi ro về dữ liệu cũ bị giữ lại trong buffer và chọn lựa giải pháp phù hợp với từng trường hợp sử dụng cụ thể.

The inside scoop on alerting changes in Kubernetes Monitoring

Grafana Cloud's Kubernetes Monitoring có hai hệ thống cảnh báo riêng biệt: cảnh báo quản lý bởi data source (Mimir/Prometheus) và cảnh báo quản lý bởi Grafana. Việc cài đặt lại app sẽ tự động chuyển quy tắc cảnh báo sang hệ thống Grafana, có thể làm gián đoạn các tuyến thông báo đã cấu hình trong Alertmanager. Bài viết hướng dẫn cách nhận diện hệ thống cảnh báo đang sử dụng, nguyên nhân ngừng hoạt động sau khi cài đặt lại, và các phương pháp tốt nhất như sử dụng nút Update thay vì cài đặt lại, sao lưu quy tắc tùy chỉnh trước khi nâng cấp, và lưu ý rằng cảnh báo quản lý bởi data source (Prometheus/Loki) sẽ ngừng hoạt động từ tháng 4/2026.

Lập trình viên cần đọc bài này để tránh mất hiệu suất cảnh báo trong Kubernetes khi tái cài đặt Grafana Cloud, vì nó có thể phá hủy cấu hình thông báo hiện có và cảnh báo cũ sẽ chuyển sang hệ thống quản lý mới, gây mất liên lạc với các hệ thống cảnh báo bên ngoài.

How to Build a Durable, Autoscaling AI Agent with Temporal, Composio, KEDA, and Kubernetes

Bài viết hướng dẫn xây dựng một runtime AI agent sản xuất có khả năng chịu lỗi, phục hồi sau sự cố nhờ Temporal, tự động scale dựa trên độ sâu queue bằng KEDA, triển khai trên Kubernetes, và tích hợp công cụ qua Composio. Kiến trúc bao gồm workflow Temporal, FastAPI gateway, container hóa bằng Docker multi-stage, triển khai trên k3d, cùng cấu hình KEDA ScaledObjects để scale-to-zero khi không có tác vụ.

Lập trình viên muốn triển khai một hệ thống AI sản xuất có độ bền cao và tự động hóa quy mô theo nhu cầu thực tế sẽ tìm hiểu cách kết hợp Temporal, KEDA và Kubernetes để giải quyết vấn đề xử lý nhiệm vụ dài hạn, tự động hóa quy mô và đảm bảo sự ổn định trong môi trường cloud-native.

AI & Kubernetes

Bài viết giới thiệu các loại workload AI trên Kubernetes, bao gồm huấn luyện (training) và suy luận (inference), giải thích lý do Kubernetes phù hợp cho huấn luyện AI nhờ khả năng quản lý tài nguyên, đồng thời đề cập đến kỹ thuật fine-tuning và prompt engineering để tối ưu mô hình AI.

Là người phát triển AI, bạn nên đọc bài này để hiểu cách Kubernetes tối ưu hóa quy trình huấn luyện và triển khai mô hình AI, từ việc quản lý tài nguyên cho việc dự đoán đến các kỹ thuật tinh chỉnh mô hình và kỹ thuật prompt hiệu quả.

Configuration management at Giant Swarm: a historical overview

Giant Swarm traces the evolution of their internal configuration management system across three eras. Starting in 2020 with static, manually deployed configs, they built a 'vintage' release system using Go templates and a config-controller to generate ConfigMaps and Secrets from a structured Git repository. Alongside it ran a 'unique apps' system using draughtsman and architect, which suffered from hardcoded management cluster lists and manual update steps. Moving to GitOps with ArgoCD then Flux, they introduced konfigure as a KRM function plugin — solving the draughtsman problem but introducing opacity, swallowed errors, and a 'poison pill' issue where one bad config stalled all reconciliation. The current system rewrites konfigure internals around a schema-driven, general-purpose rendering engine exposed as a library, backed by konfigure-operator, which isolates errors per configuration and decouples config generation from App CRs entirely.

Building a Cluster-Aware AI Agent with Kubernetes, Argo CD, and GitOps

Bài viết hướng dẫn xây dựng một AI agent chạy trong cụm Kubernetes, quan sát trạng thái cụm qua Kubernetes API và sử dụng mô hình Mistral 7B cục bộ (qua Ollama) để suy luận. Toàn bộ CI/CD được quản lý bởi GitHub Actions (build ảnh) và Argo CD Image Updater (triển khai GitOps). Agent hoạt động dưới quyền RBAC read-only, cung cấp hai REST endpoint (LLM thuần túy và RAG chẩn đoán cụm), đồng thời lưu cache trọng số mô hình trên PersistentVolumeClaim. Dữ liệu không rời khỏi cụm và không phụ thuộc vào nhà cung cấp AI bên ngoài.

Lập trình viên muốn triển khai hệ thống AI tự động hóa an toàn và hiệu quả trong môi trường Kubernetes nên đọc để hiểu cách xây dựng một agent độc lập, tuân thủ nguyên tắc GitOps và bảo mật cao mà không phụ thuộc vào dịch vụ bên ngoài.

Building a European Cloud Orchestration Platform within an Enterprise

Họ xây dựng nền tảng điều phối cloud dựa trên Kubernetes Control Plane, tận dụng các công cụ như Crossplane, External Secrets Operator, Kyverno và Flux để quản lý tài nguyên đa nền tảng (AWS, GCP, Azure) và triển khai GitOps. OpenControlPlane cho phép các nhóm dev yêu cầu Control Plane đã cấu hình sẵn, trong khi các hoạt động thúc đẩy adoption như tech talks, inner-source và giải quyết pain points chung đã giúp dự án sau đó được đóng góp cho sáng kiến IPCEI-CIS nhằm thúc đẩy chủ quyền cloud châu Âu.

Lập trình viên chuyên về cloud và DevOps sẽ tìm hiểu cách tối ưu hóa kiến trúc Kubernetes trong doanh nghiệp bằng cách kết hợp các công cụ mở nguồn như Crossplane và Kyverno để giải quyết vấn đề quản lý đa cloud và tuân thủ chính sách một cách hiệu quả.

Fix unsecured Argo CD communications

Argo CD 3.5 introduces native mutual TLS (mTLS) support for securing internal component communications, eliminating the need for service mesh sidecars or custom certificate management scripts. The post explains why mTLS is superior to one-way TLS in zero-trust environments, details the pre-3.5 workarounds (Istio/Linkerd sidecars, cert-manager, HashiCorp Vault), and provides a step-by-step setup guide. It covers both shared-certificate and per-component certificate configurations, migration patterns from existing setups, and real-world use cases including compliance with SOC 2, HIPAA, and PCI-DSS frameworks.

Building a state-of-the-art development platform with Backstage

Backstage solves the developer portal problem but not the platform problem. Many organizations end up with a fragile 'messy middle' of point-to-point integrations between Backstage and their CI/CD, GitOps, Kubernetes, and observability tools. The solution is a three-layer architecture: a portal (Backstage), a control plane that compiles developer abstractions into Kubernetes resources, reconciles drift, and aggregates runtime state, and a data plane where workloads run. Developer abstractions (components, endpoints, dependencies) and platform abstractions (environments, pipelines, traits) are kept separate. The control plane bridges them, enabling unified observability, policy enforcement, and AI agent integration. OpenChoreo is presented as an open-source CNCF sandbox reference implementation of this architecture.

Implement mTLS and zero trust with cert-manager and trust-manager

Red Hat giới thiệu phiên bản 1.19 của cert-manager operator cho OpenShift, bổ sung công cụ preview trust-manager nhằm tự động hóa việc xây dựng, phân phối và xoay vòng các gói tin cậy CA (CA trust bundles) trên các namespace Kubernetes. Khi kết hợp với cert-manager, hai công cụ này cho phép triển khai mTLS (mutual TLS) tự động ở quy mô lớn, hỗ trợ nguyên tắc zero trust thông qua quản lý vòng đời chứng chỉ ngắn hơn, gói tin cậy phân quyền tối thiểu theo namespace, và xoay vòng CA tự động.

Lập trình viên cần đọc bài này để hiểu cách tự động hóa và tối ưu hóa quản lý chứng thực mTLS cho ứng dụng Kubernetes, giúp giảm thiểu rủi ro bảo mật và tiết kiệm thời gian trong việc triển khai zero trust.

Grab Builds Secure Agentic AI Workload Platform

Grab's cybersecurity and platform engineering teams built Palana, a Kubernetes-native secure execution platform for running autonomous AI agents safely. Unlike deterministic software, model-driven agents pose unique risks including prompt injection, logic hijacking, and hallucinations. Palana addresses these through isolated Kubernetes namespaces with strict RBAC, proxy-mediated secrets management backed by HashiCorp Vault (so raw credentials never reach agent containers), and Envoy-based egress routing with Open Policy Agent rules for real-time traffic inspection and audit trails. Out-of-process control planes handle kill switches and idle shutdowns since compromised agents cannot be trusted to self-terminate. Each agent is modeled as a Kubernetes custom resource managed by a custom operator, enabling platform teams to manage hundreds of concurrent agent workloads using standard infrastructure-as-code practices.

Spotlight on WG Device Management

The Kubernetes Device Management Working Group (WG Device Management) is driving a fundamental shift in how Kubernetes handles specialized hardware like GPUs, TPUs, and FPGAs. Their primary deliverable, Dynamic Resource Allocation (DRA), recently graduated to GA in Kubernetes 1.34. DRA replaces the legacy Device Plugin API — which treated devices as opaque integers — with a structured, declarative framework covering four stages: modeling (ResourceSlice API), requesting (ResourceClaim API), scheduling, and actuation. The working group chairs from NVIDIA, Intel, and Google discuss the NP-hard scheduling challenges, cross-SIG coordination across sig-node, sig-scheduling, sig-autoscaling, sig-network, and sig-architecture, and upcoming work on device health monitoring, topology-aware multi-node scheduling, and consumable capacity sharing. NVIDIA has donated its DRA GPU driver to the Kubernetes project, and the community is growing rapidly.

Spotlight on WG Device Management

The Kubernetes Device Management Working Group (WG Device Management) is spotlighted in an interview with its three co-chairs from NVIDIA, Intel, and Google. The group's primary deliverable, Dynamic Resource Allocation (DRA), recently graduated to GA in Kubernetes 1.34. DRA replaces the legacy Device Plugin API — which treated devices as opaque integers — with a structured, declarative framework covering four stages: modeling (ResourceSlice API), requesting (ResourceClaim API), scheduling, and actuation. This enables workloads to specify fine-grained hardware requirements like GPU memory, interconnect topology, and partitioning. The working group spans five SIGs (node, scheduling, autoscaling, network, architecture) and is now focused on extending DRA expressiveness, day-two operations like health monitoring, multi-node topology-aware scheduling, and consumable capacity sharing models. Key challenges include NP-hard scheduling complexity and modeling diverse hardware. NVIDIA recently donated its DRA GPU driver to the Kubernetes project, and the community is growing rapidly.

Announcing Istio 1.30.2

Bản vá Istio 1.30.2 tập trung vào sửa lỗi và cập nhật bảo mật, bao gồm cải tiến logging cho Gateway API CRD, bổ sung trường trustDomains trong AuthorizationPolicy, và điều khiển thống kê Envoy qua biến môi trường mới. Bản phát hành cũng khắc phục nhiều lỗi nghiêm trọng như sự cố traffic khi thay đổi label Gateway, rò rỉ bộ nhớ trong krt controller, và vá 14 lỗ hổng CVE trong Envoy liên quan đến DoS, tràn bộ nhớ và lỗi tràn bộ đệm.

Lập trình viên cần đọc bài này để cập nhật về các cập nhật bảo mật và bug fix quan trọng trong Istio 1.30.2, đặc biệt là các CVE bảo mật mới như tấn công DoS HTTP/3 và lỗ hổng trong OAuth2, giúp bảo vệ hệ thống ứng dụng của họ khỏi các rủi ro an ninh mới.

Announcing Istio 1.29.5

Istio 1.29.5 là bản vá lỗi quan trọng khắc phục 14 lỗ hổng bảo mật trong Envoy (bao gồm DoS, buffer overflow, bypass xác thực SAN) cùng nhiều bug như gián đoạn lưu lượng khi thay đổi label istio.io/rev, rò rỉ bộ nhớ trong krt controller, và panic trong multicluster secret controller. Bản cập nhật cũng sửa lỗi health-probe ipset của pod ambient sau khi node khởi động lại.

Lập trình viên cần đọc bài này để cập nhật về các bảo mật và lỗi quan trọng trong Istio 1.29.5, đặc biệt là các CVE bảo mật mới như tấn công DoS HTTP/3, lỗ hổng trong OAuth2 và Zstd, giúp bảo vệ hệ thống của bạn khỏi các rủi ro mới trong ứng dụng microservices.

Google OpenRL is an Experimental Self-hosted API for LLM Post-Training Fine-tuning

Google's GKE Labs has released OpenRL, an open-source, self-hosted API designed to simplify post-training and fine-tuning of Large Language Models on standard Kubernetes clusters. OpenRL decouples reinforcement learning infrastructure from AI research concerns, allowing ML researchers to focus on RL loop design while engineers handle scaling and execution. It improves GPU utilization by running multiple RL jobs in parallel rather than sequentially, and supports macOS, Nvidia GPUs, and GKE. An included autoresearch recipe demonstrates parallel parameter sweeps for Gemma models in a text-to-SQL workflow. OpenRL also integrates with Tinker-Cookbook and is positioned alongside similar projects like FeynRL that aim to separate fine-tuning logic from system infrastructure.

How Do Self‑Hosted AI Models Change Your Kubernetes Decisions?

Running self-hosted AI models on Kubernetes introduces significant changes to how platform teams manage capacity, security, and operations. The post covers when self-hosting makes sense over API-based AI (cost predictability, data residency, vendor lock-in), what changes in cluster design (GPU node groups, autoscaling, scheduling patterns, observability), and how to split ownership between platform and ML teams. Key operational concerns include GPU utilization, new failure modes like queue depth and token latency, compliance mapping, and FinOps for GPU spend. The post also addresses when to keep Kubernetes management in-house versus using a managed service.

I need a CVE tool, it took me much less effort to build correctly

A developer builds a container vulnerability scanner with a web console on top of ConfigHub, a platform that treats configuration as queryable data. By reusing most of the scaffolding from a previously built RBAC Manager app, the CVE tool required only swapping domain-specific logic: a custom Go scanner that pulls image layers, reads OS package databases, and matches against a unified CVE database (GitHub Advisory, CVE List V5, OSV.dev). Scan verdicts are written back onto Kubernetes Deployment Units as annotations, and a Trigger gates any workload with critical CVEs — no admission webhook needed. The React web console reused ~80% of the RBAC Manager codebase, with only the model (~250 lines), snapshot query clauses, and page components replaced. The post generalizes a 5-step pattern for building internal tools on ConfigHub: define your object, load a fleet snapshot, render views, act through the API, and let policy live in ConfigHub gates.

Linkerd 2.20, the Latest Release of the Cloud-Native Service Mesh, Arrives

Linkerd 2.20 has been released with a major focus on memory efficiency, with maintainer Buoyant claiming an 85% reduction in control plane memory usage. The optimization targets key components — destination, identity, and proxy-injector services — allowing operators to run the mesh in smaller, more constrained Kubernetes clusters without losing features like mTLS, traffic splitting, or golden metrics. The release positions Linkerd as a leaner alternative to heavier service meshes like Istio and Cilium, and gives platform teams an opportunity to right-size cluster resource allocations and potentially reduce cloud spend.

Karpenter Best Practices: 10 Tips for Production Clusters

Karpenter's default configuration is not production-ready and leads to real failures like consolidation during peak traffic, ungraceful Spot interruptions, and runaway node provisioning. This guide covers 10 specific practices using the v1 stable API: running Karpenter on dedicated nodes (Fargate or tainted node group), designing mutually exclusive NodePools with taints, setting resource limits on every NodePool, enabling SQS-based Spot interruption handling instead of Node Termination Handler, pinning AMIs to tested versions, maximizing instance-type diversity for Spot, configuring disruption budgets to freeze voluntary disruptions during business hours, setting node expiry for rolling AMI freshness, using the do-not-disrupt annotation selectively, and monitoring with specific Prometheus metrics and alerts. Concrete YAML examples are provided throughout, along with edge cases like staggering expiry windows across NodePools and the 15-instance-type minimum for Spot-to-Spot consolidation.

SkyPilot Endpoints: Production-Ready Inference on Every Cluster You Own

SkyPilot Endpoints is a production-ready LLM inference system that deploys a full serving stack — inference engine, autoscaler, gateway, TLS, metrics — from a single YAML across multiple Kubernetes clusters under one endpoint URL. It handles cross-cluster placement, autoscaling, and failure recovery automatically. A key feature is unified GPU pool management: training jobs run as preemptible workloads that yield GPUs to latency-sensitive inference when demand spikes, then resume from checkpoints when capacity frees up. The stack builds on vLLM, KServe, llm-d, and KEDA, and includes KV cache-aware routing, prefill/decode disaggregation, scale-to-zero, rolling updates, and a unified observability dashboard across all clusters.

Kubernetes teams trust automation to ship code but not to touch CPU, and AI is raising the stakes

A survey of 321 Kubernetes practitioners reveals a sharp trust asymmetry: 82% trust automated code delivery, but only 27% allow automation to change CPU and memory without human review. The core reason is that resource changes alter the invisible contract between workloads and the scheduler, with failure modes that are delayed and hard to diagnose. AI inference workloads are intensifying this problem because GPU compute is expensive, inference jobs are bursty and unfamiliar, and manual optimization breaks down past ~250 changes per day. The post argues that closing the trust gap requires 'adaptive autonomy' — automation designed to work at every stage of the trust curve, from read-only recommendations to guardrailed execution to closed-loop optimization — rather than forcing full delegation upfront.

Auto-Verifying Your AI-SRE’s Fixes (Part II): HolmesGPT End-to-End on a Real Cluster

A hands-on walkthrough of an AI-SRE verification loop running end-to-end on a real Kubernetes cluster using HolmesGPT and mirrord. Two bugs are planted in a Python checkout service: an error-rate bug (item-3 ValueError causing 500s) and a latency bug (missing client-side timeout causing p99 > 300ms). HolmesGPT investigates Alertmanager alerts, a Claude wrapper converts the report into a code patch, and a verifier runs the patched code via mirrord exec against the live cluster. Scenario 1 earns a PASS verdict (error rate drops from 10% to 0%). Scenario 2 earns a REJECT verdict because caching improves p50 by 99.8% but p99 remains at 2010ms, still violating the 300ms SLO. The key insight is that the verifier catches fixes that look good superficially but don't actually clear the alert condition. Full code (~500 lines Python) is available on GitHub.

Taming the AI Double Threat with Isovalent Runtime Security

AI is creating a dual security challenge: AI workloads (especially agentic ones) introduce new attack surfaces, while adversaries use AI to compress attack timelines. Agentic workloads are non-deterministic at the application layer but exhibit stable behavioral profiles at the kernel level, making eBPF-based runtime security effective. Isovalent Runtime Security (built on Tetragon and eBPF) addresses both threats through kernel-level enforcement, process/network/file visibility, sandbox policies with default-deny posture, and L7 network introspection. The post argues that existing cloud-native runtime security primitives, extended with the right mental models, are sufficient to secure AI workloads and respond to AI-accelerated attacks.

The Dagster Almanack: Operationalizing Data Orchestration

A deep-dive into operationalizing data orchestration with Dagster, covering DevOps and GitOps best practices, code location architecture, deployment options (Kubernetes/Helm, Docker Compose, AWS ECS, Dagster+), and governance. Key themes include separating business logic from infrastructure code, using workspaces/code locations for multi-tenancy, partitioned backfills for cost efficiency, and asset-level data quality checks. Includes a reference GitHub blueprint for Kubernetes-based GitOps data platforms.

Karpenter Cost Optimization: Consolidation Benchmark Results (7-Day Run)

A 7-day benchmark comparing four Kubernetes consolidation strategies on EKS with adversarial workloads (topology spread constraints, tight PDBs, heterogeneous pod footprints, and fragmentation pods). Karpenter's native WhenEmptyOrUnderutilized policy cost $703.08. Adding Cast AI's Evictor saved 9.1% ($639.45). The Karpenter Enterprise Suite's Continuous Rebalancer saved 15.8% ($591.98). Replacing Karpenter's provisioner entirely with Cast AI's Autoscaler achieved 43.0% savings ($400.83), primarily because it evaluates workload fit at provisioning time rather than correcting packing after the fact.

Upbound Unfurls Control Plane for Managing AI Inference Workloads

Upbound has launched Modelplane, an open source control plane built on Crossplane that lets IT teams manage AI inference engines using the same declarative workflows they use for Kubernetes clusters. Modelplane supports deploying inference engines based on available GPU capacity across cluster fleets, autoscaling replicas, caching and distributing model weights, and routing inference requests through a unified gateway. Available under Apache 2 license with no usage caps, it aims to integrate AI inference workload management into existing cloud-native operations without requiring specialized staff.

AWS Cost Management in 2026: Tools, KPIs, Pitfalls, and FinOps Best Practices

A comprehensive guide to AWS cost management covering native tools (Cost Explorer, CUR, Budgets, Compute Optimizer), FinOps best practices, and key KPIs. Covers the four pillars of cost management: measure, allocate, optimize, and govern. Discusses tagging strategies, rightsizing, Savings Plans, Spot Instances, Kubernetes cost allocation, AI workload governance, and common pitfalls like spreadsheet forecasting and ungoverned AI spend. Also introduces agentic FinOps concepts with autonomous detection, investigation, and orchestration agents. Concludes with signals indicating when teams should move beyond native AWS tools to a third-party FinOps platform.

Client-Side Load Balancing at a Million Requests Per Second

Zalando's engineering team built an in-process client-side load balancer (CSLB) to handle over a million requests per second of internal fan-out traffic for their Product Read API, replacing shared Skipper ingress hops. The implementation replicates Skipper's xxHash64 consistent-hash ring for cache locality, uses a Kubernetes watch-based informer for pod discovery, and adds N-ring fade-in to prevent cold-cache spikes on scale-up. A key innovation is occupancy-based bounded load using Little's Law (seconds of work per second) rather than in-flight counts or throughput, combined with a latency multiplier borrowed from Finagle. Results include eliminating Skipper's fleet from 50+ pods to 8, reducing their own pod fleet by 25%, and saving over $1,000/day. AZ-aware routing was prototyped but paused due to edge cases around bounded-load threshold miscalculation during dual fade-in. The post also covers pipeline improvements, retry hardening, FIFO buffering, and how detailed logging revealed mysterious node-level network freezes that had previously been invisible.

Connect EvalHub to protected production model servers

Connecting EvalHub to protected production model servers requires different authentication strategies depending on the model type. Three patterns are covered: (1) ServiceAccount tokens for internal OpenShift AI models using RBAC RoleBindings with no secrets needed, (2) API keys for external models like OpenAI stored as Kubernetes secrets, and (3) combining API keys with custom CA certificates for self-hosted models behind private TLS. The guide includes concrete kubectl commands, job configuration JSON, troubleshooting steps for common errors like HTTP 401 and SSL failures, and a real-world scenario evaluating three different model types simultaneously.