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

Kubernetes 1.18

kubernetes.io

Post reply on HN
Print view View original

61–70 of 132 posts

Re: Kubernetes 1.18

#61

Post by dilyevsky »

eric_khun wrote: post #55
dilyevsky wrote: post #49

Earlier quoted context omitted.

1. It makes no sense to quota your cpu with the exception of very specific cases (like metered usage). You’re just throwing away compute cycles 2. Same applies to dedicate cores for pretty much same reasons Having said that if you really really want quota but don’t want shit tail latency I suggest setting cfs_quota_period to under 5ms via kubelet flag

Thanks! wouldn't that be an issue if a pod "take over" the node , if for some reasons a request use too much CPU?

Not really if you ensure every pod sets cpu request (which sets up cgroups cpu.shares) and your kubelet and system services are running in separate top-level cgroups (—kube-reserved and —system-reserved flags) you have reserved enforcement enabled. On full node contention every container will just consume its proportional share. This is not to say that someone malicious wouldn’t be able to dos a node but untrusted workload is a whole separate topic

Re: Kubernetes 1.18

#62

Post by Legogris »

merb wrote: post #23
kawsper wrote: post #18

Earlier quoted context omitted.

Nomad and Consul from Hashicorp.

which is way more complex to setup than k3s

When was the last time you used it? I found it straightforward and not so many knobs to twist. ACLs and cert management can be a bit of a PITA the first time (especially the former, and it’s something you really want to do before you’re replying on Consul for mission-critical stuff), but that’s about it. Still, those two things are mainly confusing due to poor documentation and not that complicated once you get up to speed, so it’s mainly the first time you do a new setup.

Re: Kubernetes 1.18

#63

Post by jasdfajdsfk »

ojhughes wrote: post #56
taywrobel wrote: post #2

Reminder to everyone that unless you have a truly massive or complex system, you probably don’t need to run K8s, and will save yourself a ton of headaches avoiding it in favor of a more simple system or using a managed option.

This false information really needs to die. k8s is a sane choice in many cases not just hyper scale. Regular business apps benefit from rolling upgrades and load balancing between replicas. Managed k8s platforms like GKE make cluster management a breeze. Developer tooling such as Skaffold makes developing with k8s seamless. I expect k8s to continue growing and will soon take over much of the existing Cloud Foundry es…

false? the only thing false here is k8s marketing - k8s is never a sane choice, it is insecure, performance sucks and costs companies unbelievable amounts of dough

k8s deserves to die in a fire

Re: Kubernetes 1.18

#64

Post by jasdfajdsfk »

gigatexal wrote: post #53
dragonsh wrote: post #52

Containers are not necessary if the systems are build with something like Guix or Nix as they provide transaction level updates to applications and dependency and secure by default as no need to run a daemon with root access to run, monitor and manage containers. They provide same way of managing application deployment, the way application source code is managed with versioned deployments and rollbacks all baked in.…

Kubernetes is here. Better to learn it and use it where appropriate than to fight it.

lol, you are such a fucking loser

Re: Kubernetes 1.18

#66

Post by p_l »

jarfil wrote: post #21
outworlder wrote: post #8

Earlier quoted context omitted.

Not sure why this disclaimer has to be posted every time there's a discussion on K8s. It is a tool, if you need to use it, do use it. If not, don't. Although I would argue that you need to know what trade offs you are making if you have the right use-case (multiple containers you need to orchestrate, preferably across multiple machines) and you are not using it or a similar tool. There are lots of best-practices and…

You can migrate docker deployments to K8s just by adding the parts you were missing, so when in doubt, it always makes sense to start with docker, docker-compose, and only consider K8s as an alternative to docker swarm.

In practice, I found docker to be much more brittle than kubernetes, even when kubelet uses docker underneath. K8s minimizes the amount of "features" used from docker, and unlike docker is properly designed for deployment use out of the box (and generally has cleaner architecture, so figuring out server failures tended to be easier for me with k8s than with docker daemon)

Re: Kubernetes 1.18

#67

Post by hodgesrm »

QUFB wrote: post #41

I've seen the cloud agnostic nature of Kuberbetes mentioned in many posts here. This is only true on the surface for a significant number of use cases and deployment models. Once petabytes of data are out there in your GCP or AWS environment, "portability" will be costly due to extortionistic pricing of egress bandwidth.

A lot of people think of multi-cloud as some kind of arbitrage where you jump quickly between markets. Running applications in cloud environments is a lot more like leasing property. Once you set up there are costs to moving.

The portability argument boils down to saying you are not boxed in. If things get bad enough you can move. This is a big long-term advantage for businesses because it means you can correct mistakes or adjust to changing business conditions. That's what most people who run companies are really looking for.

Re: Kubernetes 1.18

#68

Post by p_l »

dragonsh wrote: post #52

Containers are not necessary if the systems are build with something like Guix or Nix as they provide transaction level updates to applications and dependency and secure by default as no need to run a daemon with root access to run, monitor and manage containers. They provide same way of managing application deployment, the way application source code is managed with versioned deployments and rollbacks all baked in.…

As much as I like Guix (and like the idea of Nix but find it infuriating to actually work with), they don't solve anything that is covered by kubernetes, except possibly building of container images (as one can equate OCI containers with nix closures).

Where does Nix/Guix manage dynamic binpacking of applications to servers (preferably without a blood sacrifice on the altar of "infinite recursin")?

Where do they handle nicely (de)provisioning and attachment/detachment of special resources, whether those are filesystems, block devices, any kind of special device etc.?

How about integrating various special networking resources like load balancers?

No, NixOps and related do not handle it well, as they need static assignment upfront and can't dynamically adjust as the system runs. Even at my small scale, all those features above are crucial, and k8s let's me not worry about problems most of the time (Rarely we have a black swan, that pretty much always ends up being "not k8s fault that network died or nginx got hung")

Re: Kubernetes 1.18

#69

Post by dragonsh »

glass_of_water wrote: post #60
dragonsh wrote: post #52

Containers are not necessary if the systems are build with something like Guix or Nix as they provide transaction level updates to applications and dependency and secure by default as no need to run a daemon with root access to run, monitor and manage containers. They provide same way of managing application deployment, the way application source code is managed with versioned deployments and rollbacks all baked in.…

Could you elaborate on your what your stack looks like and what tools you use other than Guix? What made you choose Guix over Nix?

Homoiconicity of lisp made me go with Guix over NIX. I work with lisp and guile felt much more natural, another reason is guix documentation is really very good.

Re: Kubernetes 1.18

#70

Post by gtaylor »

alpb wrote: post #30
yahyaheee wrote: post #16

Earlier quoted context omitted.

You have vendor lock-in with all of these though

Not really, no. Cloud Run implements the Knative API, so you can actually take it away and run it on any Kubernetes cluster anywhere on a cloud or in your datacenter.

Doesn't that require Istio and a few other things as well? I wouldn't wish Istio configuration and maintenance on anyone but the larger shops/teams. You might not be technically locked in, but not everyone can afford to dedicate the attention to tuning and maintaining Istio.

Source: at mid-sized company who has Istio in the stack.

Post reply on HN