<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Karpenter on nanta - Data Engineering</title><link>https://nanta-data.dev/en/tags/karpenter/</link><description>Recent content in Karpenter on nanta - Data Engineering</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 nanta</copyright><lastBuildDate>Mon, 09 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://nanta-data.dev/en/tags/karpenter/index.xml" rel="self" type="application/rss+xml"/><item><title>AWS EC2 Instance Architecture Comparison: ARM Graviton4 vs AMD Turin — Is the Fastest Instance the Best Choice?</title><link>https://nanta-data.dev/en/posts/ec2-instance-architecture-comparison/</link><pubDate>Mon, 09 Mar 2026 00:00:00 +0000</pubDate><guid>https://nanta-data.dev/en/posts/ec2-instance-architecture-comparison/</guid><description>In the 2026 cloud VM benchmarks, AMD EPYC Turin (C8a) dominated both single-threaded and multi-threaded performance. Should we migrate our Graviton (ARM) data platform infrastructure to C8a? After analyzing the vCPU vs physical core distinction, Spot price-to-core efficiency, and workload characteristics — the conclusion is that a hybrid strategy beats a full migration.</description></item><item><title>EKS AI Serving Node Cost Reduction: Instance Diversification, Consolidation, and Scheduled Scaling</title><link>https://nanta-data.dev/en/posts/eks-ai-platform-cost-saving/</link><pubDate>Thu, 05 Mar 2026 00:00:00 +0000</pubDate><guid>https://nanta-data.dev/en/posts/eks-ai-platform-cost-saving/</guid><description>An AI platform team&amp;rsquo;s serving API was running 500 fixed pods on only two on-demand instance types (c6i.2xlarge, m6i.2xlarge). We applied instance type diversification and Karpenter consolidation as phase 1, then KEDA cron-trigger scheduled scaling as phase 2. Key finding: consolidation alone has limited effect when pod count is fixed — it needs scale-in to actually reduce node count.</description></item><item><title>Adopting Trino Gateway: Zero-Downtime Deployments and Multi-Cluster Routing</title><link>https://nanta-data.dev/en/posts/trino-gateway-zero-downtime/</link><pubDate>Fri, 27 Feb 2026 00:00:00 +0000</pubDate><guid>https://nanta-data.dev/en/posts/trino-gateway-zero-downtime/</guid><description>Trino doesn&amp;rsquo;t support coordinator HA. Redeploying the coordinator means downtime. We adopted Trino Gateway to enable Blue/Green deployments with zero downtime and route BI/OLAP queries to separate clusters based on HTTP headers.</description></item></channel></rss>