Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What job interviews taught me about Kubernetes

notnotp.com

Post reply on HN
Print view View original

221–230 of 233 posts

Re: What job interviews taught me about Kubernetes

#221

Post by Thaxll »

mickael-kerjean wrote: post #79
Thaxll wrote: post #55

Earlier quoted context omitted.

k8s is not a pain, I would never return to something like Pupet / Ansible / etc ... to deploy bare ec2 instances, it's just re-inventing the wheel badly. Just use ECS / Fargate with an ALB in front if you need a simpler use case.

I've had the opposite experience. I used to run k8s on bare metal, troubleshooting something at least once a month (DNS going down was a recurring favorite). The breaking point came with the churn in the ecosystem, got bitten by the deprecation of the community darling weave net cni plugin, the killing of the nginx ingress was the nail in the coffin knowing I had way too many annotation tight to the ingress that it w…

Don't run k8s on bare metal if you don't have a good platform team though. Using a cloud provider ( eks / aks / gke ) is trivial and "problem" free.

I've never had DNS problems going down, the only thing I've seen is app that would create too many iptables entries when flooding request dns ( app problem ).

Re: What job interviews taught me about Kubernetes

#222

Post by rienbdj »

WorldMaker wrote: post #197
aweiland wrote: post #187

Earlier quoted context omitted.

Any good ones people would recommend?

In my experience I tried a few and kept returning to just Typescript with a good YAML serializer library. Most of what you need in YAML programming is "Typed JSON" and Typescript is an excellent "Typed JSON" and "Typed JSON modularization and merger tool". Then just a little bit of glue code to pass your finished "Typed JSON" into a YAML serializer, depending on any "complex" YAML features you might need.

Not a bad solution at all. It does require some discipline to write deterministic templates etc. though.

Re: What job interviews taught me about Kubernetes

#223

Post by nijave »

singron wrote: post #99
mikeocool wrote: post #14

I made this decision at a startup (albeit when the eng team was ~30 people, and we had a monolith with ~10 supporting services). I wouldn’t do it again, even for the reasons stated in the article. The uniformity is nice, we were moving from apps running directly ec2 instances provisioned with ansible. Each time we spun up a new service it was a process to get the ec2 instances provisioned just so. But k8s is such a p…

I really wish there was an 80% kubernetes. I think you could get there with some changes: 1. No overlay networks. 1 IP per machine. pods use dynamically allocated ports, and the kubelet enforces pods listen only on their assigned ports using seccomp. 2. No kube-proxy or equivalent Layer-4 "load-balancer". It's not good, but it's often used. You should use some kind of Layer-7 load balancing instead. Also you need to…

1 & 2 you can do with k8s host network on pods and nodeports

ECS is a simpler alternative if you're on AWS.

Re: What job interviews taught me about Kubernetes

#224

Post by jachee »

bakies wrote: post #212
TZubiri wrote: post #184

Earlier quoted context omitted.

on the other hand, it might be a benefit that an AI can't spin up instances. Do I want potential to increase expenditure by infinite percent? Or do I want to sign a contract for 2 500$/mo dedicated servers? Let's be real the latter can handle 20k concurrent users without breaking a sweat, and that's like 99.9% of companies and projects.

Oh what would I do with $2,500 a month in dedicated servers..? Kubernetes.

That was two $500/mo servers, not $2500/mo.

Re: What job interviews taught me about Kubernetes

#226

Post by threethirtytwo »

linksnapzz wrote: post #218
linksnapzz wrote: post #193

Earlier quoted context omitted.

This so isn't true, that it's not even wrong.

Ahem: “Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” ― Edsger Wybe Dijkstra

This quote is a common myth and a perversion of what he really said:

“Complexity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: simplicity sells better.” ― Edsger Wybe Dijkstra

That's what he actually said, but many source misattribute the inverted version of the quotation.

Re: What job interviews taught me about Kubernetes

#227

Post by SOLAR_FIELDS »

ajayvk wrote: post #94
SOLAR_FIELDS wrote: post #78

Earlier quoted context omitted.

I look forward to the evolution of your project into a less standardized Kubernetes as end users request more and more features of your project.

Targeting a specific use case (internal tools) should hopefully help avoid feature creep. Also, the goal is that an OpenRun config should work on a single-node with Docker and with Kubernetes. That limits the types of features which can be implemented (for example no Docker Compose support, no Helm support).

[dead]

Re: What job interviews taught me about Kubernetes

#229

Post by linksnapzz »

threethirtytwo wrote: post #226
linksnapzz wrote: post #218

Earlier quoted context omitted.

Ahem: “Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” ― Edsger Wybe Dijkstra

This quote is a common myth and a perversion of what he really said: “Complexity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: simplicity sells better.” ― Edsger Wybe Dijkstra That's what he actually said, but many source misattribute the inverted version of the quotation.

[dead]

Re: What job interviews taught me about Kubernetes

#230

Post by codemog »

quibono wrote: post #174
codemog wrote: post #109

It's not uniformity, it's cargo culting and offloading thinking to group norms. Doesn't help engineers are some of the most arrogant people alive and refuse to admit anything is complicated, as they consider it some kind affront to their intelligence. I would not advise asking the majority of CTOs these questions either. Many got to that position by saying what people want to hear, which is the "average" safe answer.…

I think a big part of this whole discussion (and why it's always such a divisive topic) is that there are so many factors to consider that there is no one single golden bullet. An industry standard just makes this issue go away; also it makes the decision making easier since you're not taking risks going for "VM-with-systemd" or "plain docker" or "bare metal" over $STANDARD. > I would not advise asking the majority o…

I believe a better phrasing for this is “standards change but your program will always be crappy”. Meaning if you choose all the popular tools and languages of the era because they’re standard and not because they’re the right fit for the project, the standards will eventually evolve and move on like they always do, but your program will sit fossilized and bad.
Post reply on HN