Karpenter out of beta, Remote debug pod, Kubernetes deprecated services, Rate limit and whitelist

Hello Team,

Take a look at this week’s changelog, which features some exciting updates and enhancements from our team!

#Karpenter out of Beta with additional control feature

After a long journey, we’re excited to announce that the Karpenter feature is officially out of beta! Karpenter, the advanced EKS node autoscaler, is designed to optimize resource usage for clusters running on AWS. For more details, check out here.

Here’s what’s new:

• Default for Non-Production Clusters: Karpenter is now the default node autoscaler for all non-production clusters.
• Production Cluster Compatibility: You can enable Karpenter for new production clusters, and soon, you’ll also be able to migrate existing production clusters to Karpenter.

Additionally, we’ve introduced a couple of key features to help you control costs and manage your resources more effectively:

• Consolidation Scheduling: You can now define when the consolidation process occurs for your node pools. Consolidation ensures pod allocation across nodes is optimized, minimizing fragmentation and reducing overall cluster costs.
• Nodepool Limits: Set maximum CPU and memory usage for node pools, allowing you to control resource consumption and keep your cluster costs in check.

(if you're interested, check out these two articles where we share some valuable lessons we learned while installing and configuring Karpenter)

#Connect to your Kubernetes cluster via the remote debug pod

We’ve introduced a new CLI command that simplifies connecting to your Kubernetes cluster without requiring credentials. Note: This feature is restricted to admins, and all connections are logged in the audit logs for security and transparency.

Technically, this feature deploys a dedicated debug pod on your cluster, preloaded with useful tools like kubectl and k9s. It’s an invaluable resource when you need to debug or investigate issues directly from your local machine.

#Identify services using deprecated Kubernetes API

At Qovery, part of our job is ensuring that when your cluster is upgraded to a new Kubernetes version, the applications deployed through our “Application,” “Database,” and “Job” services remain fully compatible with the latest version.

However, if you deploy your own applications or third-party services via a Helm chart, you are responsible for ensuring those charts are compatible with the new Kubernetes version.

To make this process easier, we’ve developed a new feature that:

• Recaps Deprecated API Usage: you’ll now see a summary in the cluster logs of any services using Kubernetes APIs that are slated for deprecation in the next version. While this is currently a warning message, we strongly recommend addressing it promptly by upgrading your Helm charts to a compatible version.
• Blocks Cluster Upgrades with Incompatibilities: if any incompatibilities are detected with the upcoming Kubernetes version, the cluster upgrade process will be halted until the issues are resolved.

This feature helps you proactively address potential problems and ensures a smoother upgrade process.

#Applying Rate Limiting and Advanced Whitelist on your services

To help better protect your applications—especially if you don’t already have these safeguards provided by an external service like a CDN—we’ve introduced two powerful new features:

• Rate limiting: define custom rate-limiting rules for the traffic your application receives. These rules can be general or tailored based on specific request attributes. For more details on configuring rate limiting, check out our guide here.
• Advanced IP Whitelist: Create advanced whitelisting rules based on request attributes. For example, you can allow traffic from a specific IP address only if it includes a particular $Token value in the request header. Learn how to set up advanced whitelisting in our guide here

#Minor Changes:

• VPA charts upgrade: we have upgraded the VPA chart to the latest version so that we will ready to upgrade your cluster to the Kubernetes 1.31.
• Removed QOVERY_DEPLOYMENT_ID variable: Following our post here, we have removed the deployment id environment variable from every service.

For the latest news and upcoming features, remember to check out changelog.qovery.com.

As always, we appreciate your feedback and support.

Happy Deploying!

The Qovery Team 🚀