Hi Qovery Team!
We need to ensure that the EC2’s of our EKS cluster are being regularly patched with security updates in order to meet our organization’s compliance requirements.
From what we can see, patches aren’t applied regularly unless we “cycle out” the instances. We can force an update by changing the cluster EC2 type, so what we find ourselves doing is changing the type and setting it back to get the latest AMI (for example: change the instance type from a 2xlarge to a 4xlarge and back to a 2xlarge).
However this is a manual process, and when we don’t do this, the EC2’s don’t appear to be updated very regularly (at all?). The update history on our EKS node group shows the nodes in our non-production cluster have not had a version upgrade since March, which is shortly after they were deployed. So we are having to manually do this cycle process whenever we need to patch.
Ideally:
We would know if there are vulnerabilities in our current EC2’s that need to be addressed
We would know if there are security patches available
We would have an easier way to apply them, or possibly a way to automatically apply them
Do you have any guidance for how we can best handle this?
We plan to support it with Karpenter by default at Qovery. Karpenter is already available as beta on Qovery and supports this feature (doing approximately what you describe). We’re still in a testing phase with several customers before going to production.
In the short/mid-term, all customers will be upgraded to Karpenter and nodegroups will no longer be supported by Qovery. So every customer will benefit from this feature.
Hello @Kyle_Flavin
You can already create a new cluster using Karpenter (non-production). In a few days, you’ll be able to install Karpenter directly into your existing non-production cluster, avoiding the need to recreate a new one.
For production clusters, we’re still gathering feedback before making this available, which is planned for Q4 of this year.
Would you be willing to test it on your non-production cluster and let us know if everything works smoothly? I’ll contact you when it’s possible to activate it directly in your existing cluster.
Hi Julien,
Unfortunately I don’t have a cluster we can test in. I need Karpenter to be GA before I can install it in our non-production cluster. It’s used quite a bit and I’m not comfortable installing something in beta, especially because (my understanding is) we can’t roll it back if there’s a problem.
I understand yes you can’t rollback your existing cluster if you enable Karpenter on it. However it will still be possible to create a new cluster and migrate your environments on it if you encounter issues with Karpenter.