91–100 of 135 posts
Earlier quoted context omitted.
And Red Hat Core OS (RHCOS) for Red Hat flavored shops.
Red Hat bought the company that created CoreOS so it's not surprising they have Red Hat/Fedora supported versions right?
Earlier quoted context omitted.
Constantly rotating nodes in and out of the cluster and restarting/relocating pods, even if mostly automated, causes a lot of needless infrastructure strain. It is IMO one of the most overlooked parts of Kubernetes, and I wish there was a better solution to maintain stable, long-running processes when needed.
If your pods need to be long running, you can annotate them as such and they will not be autoscaled. https://github.com/kubernetes/autoscaler/blob/master/cluster...
Earlier quoted context omitted.
Yep you are right about SIGTERM, but let's think back to the original reason why we wanted to update the node: because of a patch, probably a security patch for a CVE? What is the better option here? Implement a SIGTERM based process that allows the user to block the patch for a critical, possibly zero-day CVE for xx hours, remaining in a vulnerable state the entire time? Or implement a system that just patches the u…
If there's a CVE vulnerability that is being actively exploited on your network, you should preempt running processes to deal with it, and absolutely must take the boot+nuke approach, because it already could be affecting any host that has not already been boot+nuked? If there's not a CVE, AWS can significantly manage the lifecycle of their machines, and have ~5% of all of their machines "unschedulable" at any one ti…
These assumptions you're making are dangerous because the variety of workloads across tenants is extreme. If you're going to do something like "kill compute no matter what" then you better have a good reason for it.
Earlier quoted context omitted.
We use 5000+ CoreOS nodes in production and never want to go back to replacing VMs with new images for each update again. In-place immutable updates are more efficient and faster. Unlike RPM based OSes that are hard to patch, transactional updates provide a safe way to perform safe in-place updates instead of wasteful operations such as replacing full VMs for small OS updates.
As a former CoreOS (now Red Hat) employee, I'm glad to hear of your success with the product and it's awesome to see that scale giving you time back in your day to concentrate on the big picture.
Earlier quoted context omitted.
I can provide a little background on this. In general yes I would recommend that you just use an ASG and roll out a new AMI. However that approach can be very expensive and time-consuming at truly massive scale (1000's or even 10's of thousands of machines). Bottlerocket is built in part based on our experiences operating AWS Fargate, which obviously has as one of its needs the ability to patch a colossal number of h…
A little confused, you say you don't want to disrupt the containers, but https://github.com/bottlerocket-os/bottlerocket#updates seems to indicate you still have to reboot for the update to take hold?
[1] https://github.com/bottlerocket-os/bottlerocket/tree/develop...
Earlier quoted context omitted.
> If you're using an ECS or EKS Cluster, you still have to run some operating system on the ECS Container Instances. The containers have to run somewhere. Forgetting Fargate there?
I literally mentioned Fargate in the same comment: >> It would hopefully feel more similar to using Fargate than not, except without paying the higher price for Fargate, and having access to the wider variety of hardware configurations available to regular ECS. If you're using an ECS Fargate Cluster or EKS Fargate Cluster, I don't consider those the same as an ECS Cluster or EKS Cluster. Unfortunately, there's no spe…
As strong as the engineering behind Bottlerocket seems to be, I'm not entirely sure who they built it for, except as a foundational component for AWS's managed offerings. If you, as an AWS customer, decide to fully embrace AWS lock-in, then why would you run this yourself on an EC2 instance instead of running ECS or EKS? If you're trying to avoid AWS lock-in, why would you choose an OS that's locking you into AWS Sys…
Hi I'm a developer advocate in the container engineering org at AWS. I think there are a few misunderstandings here that I may be able to explain better. First Bottlerocket is not Amazon Linux 2, it is its own minimal operating system, with most components built from the ground up in Rust. This is totally different than the Amazon Linux 2 you may be familiar with (and most other operating systems for that matter). Bo…
Earlier quoted context omitted.
If there's a CVE vulnerability that is being actively exploited on your network, you should preempt running processes to deal with it, and absolutely must take the boot+nuke approach, because it already could be affecting any host that has not already been boot+nuked? If there's not a CVE, AWS can significantly manage the lifecycle of their machines, and have ~5% of all of their machines "unschedulable" at any one ti…
I don't know your background but the way you respond makes me think you have not been responsible for systems that multiple tenants rely on for varying workloads. These assumptions you're making are dangerous because the variety of workloads across tenants is extreme. If you're going to do something like "kill compute no matter what" then you better have a good reason for it.