I've climbed the mountain of learning the basics of kubernetes / EKS, and I'm thinking we're going to switch to ECS. Kubernetes is way too complicated for our needs. It wants to be in control and is hard to direct with eg CloudFormation. Load balancers are provisioned from the add-on, making it hard to reference them outside kubernetes. Logging on EKS Fargate to Cloudwatch appears broken, despite following the docs. CPU/Memory metrics don't work like they do on EKS EC2, it appears to require ADOT.
I recreated the environment in ECS in 1/10th the time and everything just worked.
I've been running ECS for about 5 years now. It has come a long way from a "lightweight" orchestration tool into something thats actually pretty impressive. The recent new changes to the GUI are also helpful for people that don't have a ton of experience with orchestration.
We have moved off of it though, you can eventually need more features than it provides. Of course that journey always ends up in Kubernetes land, so you eventually will find your way back there.
Logging to Cloudwatch from kubernetes is good for one thing... audit logs. Cloudwatch in general is a shit product compared to even open source alternatives. For logging you really need to look at Fluentd or Kibana or DataDog or something along those lines. Trying to use Cloudwatch for logs is only going to end in sadness and pain.
GKE is a much better product to me still than EKS but at least in the last two years or so EKS has become a usable product. Back in like 2018 though? Hell no, avoid avoid avoid.
I started with ECS (because I wanted to avoid the complexity of K8s) and regret it. I feel I wasted a lot of time there.
In ECS, service updates would take 15 min or more (vs basically instant in K8s).
ECS has weird limits on how many containers you can run on one instance [0]. And in the network mode where you can run more containers on a host, then the DNS is a mess (you need to lookup SRV records to find out the port).
Using ECS with CDK/Cloudformation is very painful. They don't support everything (specially regarding Blue/Green deployments), and sometimes they can't apply changes you do to a service. When initially setting up everything, I had to recreate the whole cluster from scratch several times. You can argue that's because I didn't know enough, but if that ever happened to me on prod I'd be screwed.
I haven't used EKS (I switched to Azure), so maybe EKS has their own complex painful points. I'm trying to keep my K8s as vanilla as possible to avoid the cloud lock-in.
Interesting that you say you worry about re-creating the cluster from scratch because I've experienced exactly the opposite. Our EKS cluster required so many operations outside CloudFormation to configure access control, add-ons, metrics server, ENABLE_PREFIX_DELEGATION, ENABLE_POD_ENI... It would be a huge risk to rebuild the EKS cluster. And applications hosted there are not independent because of these factors. It makes me very anxious working on the EKS cluster. Yes you can pay an extra $70/month to have a dev cluster, but it will never be equal to prod.
On the other hand, I was able to spin up an entire ECS cluster in a few minutes time with no manual operations and entirely within CloudFormation. ECS costs nothing extra, so creating multiple clusters is very reasonable, though separate clusters would impact packing efficiency. The applications can be fully independent.
> ECS has weird limits on how many containers you can run on one instance
Interesting. With ECS it says for c5.large the task limit is 2 with without trunking, 10 with.
In ECS I had to recreate the cluster from scratch because some of the changes I wanted to do, CDK/CF wouldn't do.
My approach on Azure has been to rely as little as possible in their Infra-as-code, and do everything I can to setup the cluster using K8s native stuff. So, add-ons, RBAC, metrics, all I'd try to handle with Helm. That way if I ever need to change K8s provider, it "should" be easy.
To add to my other comment: AFAIK Ruckus is not targeting consumers. They sell to managed services providers and probably even then not directly but through a reseller. The MSRP for APs in this sense is much like MSRP for rack servers - it's huge on paper but in reality the price is chipped away by volume discounts, long term agreements and licenses. Retired(yet perfectly capable) APs go through ITAD and end up on ebay/craigslist for much better prices.
I have been running Ruckus I got off ebay for quite a while now. Flashed it into unleashed mode and it has been rock solid. In fact I am typing this comment while being about 100 ft away from the AP.
I was surprised to learn that PFAS are in dental floss, used to help in glide between teeth easily. This study linked using such floss and higher blood concentrations of PFAS: https://www.nature.com/articles/s41370-018-0109-y It's not strong enough evidence to suggest we should stop flossing, but they do make plain floss without PFAS, ex: https://www.amazon.com/gp/product/B005IHMXEQ/
How well does OPNsense deal with bufferbloat in a home networking situation? It appears to implement fq_codel for traffic shaping, but not the newer cake algorithm. Test: https://www.waveform.com/tools/bufferbloat
Debacle with wireguard? Opnsense has wireguard easily available. Also, it's just base wireguard, so you don't have to go through any extra steps of trying to understand / trust other additions on top of it, which is very nice IMO.
I'm referring to the kernel implementation of it, unless you weren't. But I think you likely are, considering it is now in the mainline FreeBSD kernel. But this took more than 2 years after it was mainlined into the Linux kernel[1], and the delay was largely was because of what happened regarding it's initial implementation[2]. That's the debacle I'm talking about.
However, glucose can be stored and metabolised throughout the body whilst fructose requires processing in the liver. Our bodies are not designed to have a large instantaneous "hit" of fructose. They can cope with slow release of natural fructose in fruits, but in processed food it's soluble and released very quickly. The kinetics of how it's processed are very different.
Humans didn't eat a lot of sugar until fairly recently, too. And even if you did, you'd have to be very, very rich to be eating it 3 meals a day.
Now you can get sugary cereal for breakfast, sandwich bread with HFCS for your lunchtime sammo, and a curry jam packed with palm oil and sugar for dinner. And that doesn't count the cookies or Pepsi you slam in between.
Raw sugar of HFCS -- don't matter none, it's that you're slamming em at each meal, all the time.
Fructose is an appetite stimulant, so eating a lot of it will change your eating habits. And we definitely eat more fructose than a few generations ago.
Huge chlorine (chlor-alkali) plants using mercury cells produce “mercury-grade” caustic soda, hydro- chloric acid and other chemicals which are, in turn, used to produce thousands of other products, in- cluding food ingredients such as citric acid, sodium benzoate and HFCS.2 The mercury in these plants can contaminate their chemical products, as well as the broader environment.
In HFCS production, caustic soda and hydrochloric acid are used to separate corn starch from the corn kernel, as well as to adjust the pH of the process. The HFCS industry, according to Vulcan Chemical Company, former operator of one of these plants, is a primary user of “mercury-grade” caustic soda and hydrochloric acid.2 The Environmental Health commentary provides data substantiating that mercury contaminating commercial HFCS is a problem.
In the fall of 2008, we looked for total mercury in 55 brand-name food and beverage products where HFCS was the leading or second highest ingredient. An independent laboratory found total mercury, above the limit of detection, in about one in three products, including: dairy beverages, soft drinks, salad dressings, barbecue sauces, flavored syrups and jams. In other words, we found total mercury across the range of foods and beverages in which HFCS is routinely used.
I set up an account with the public DNS provider and it doesn't appear to support multiple entries per record type. For example, time.cloudflare.com has two A records but the UI only shows the one.
The great thing about anycast is the IPs are the same for everyone, it’s just which POP routing converges on that is different. DNS and anycast are combined primarily for load balancing and failover. Anyone can get and use the IPs directly with dig.
Right, but unless it's documented how do you know that the DNS entry won't change? They could change infra so it's DNS load-balanced instead of anycast and still at time.cloudflare.com
It wasn't clear but I provided the IP so others could validate it's the same for them and (in the future) that it hasn't changed.
Interesting! Unfortunately due to write endurance many networking devices mount their filesystem read-only. This means they also sometimes lack a log file describing why the device shut down!
I recreated the environment in ECS in 1/10th the time and everything just worked.