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

51–60 of 132 posts

Re: Kubernetes 1.18

#51

Post by kube-system »

threatofrain wrote: post #17

Anyone have a recommended guide for Kubernetes?

They're all bad. The official docs are the only place to go. Half of the time other resources are out of date or just plain wrong.

Start here: https://kubernetes.io/docs/tutorials/ Look at all the diagrams in the tutorials but don't bother with the interactive stuff.

Then learn the more detailed concepts here: https://kubernetes.io/docs/concepts/

Once you understand the lingo and the general idea of what the different functions are supposed to do, just copy some example deployments and try to get something of your own working.

Re: Kubernetes 1.18

#52

Post by dragonsh »

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.

But as with any technology Guix and Nix are still decade ahead of the present and may pick up later when technology converge back to running application servers and other dependent software in isolation with user level namespaces.

Kubernetes try to solve one problem and create 10 other infrastructure problems to manage and instead of working on application, tie the company to a specific distribution or cloud service provider. So far there is nothing revolutionary in it unless the startup or company adopting k8s is google size operations.

From a software developer perspective which is the main audience of HN it will be popular as most of them dream or wants to work for company of size google. Startup founders want to solve the scaling problem like google in the beginning as everyone dreams to be google size from day one. Kubernetes complexity is useful at large scale for majority i.e. over 90% of the deployments simple containers, bare metal or VM with traditional configuration management will be sufficient.

Re: Kubernetes 1.18

#53

Post by gigatexal »

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.

Re: Kubernetes 1.18

#54

Post by dragonsh »

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.

I don't need to fight it, I am not looking for a job and follow the herd mentality. My own startup is pretty happy with Guix and related infrastructure on bare-metal, it works well for us and we can still stand on shoulders of giants who have done much better job in managing large distributed infrastructure.

Re: Kubernetes 1.18

#55

Post by eric_khun »

dilyevsky wrote: post #49
eric_khun wrote: post #48

Anyone solved properly the CPU Throttling issues they are seeing with kubernetes ? Is this release solved it? We are seeing a lot of throttling on every deployments, what impact our latency, even when setting a really high cpu limit. The solutions seems to be: - remove the limit completely. Not a fan of this one since we really don't want a service going over a given limit... - using the static management cpu policy…

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?

Re: Kubernetes 1.18

#56

Post by ojhughes »

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 estate in F500 companies .

Re: Kubernetes 1.18

#57

Post by snupples »

eric_khun wrote: post #48

Anyone solved properly the CPU Throttling issues they are seeing with kubernetes ? Is this release solved it? We are seeing a lot of throttling on every deployments, what impact our latency, even when setting a really high cpu limit. The solutions seems to be: - remove the limit completely. Not a fan of this one since we really don't want a service going over a given limit... - using the static management cpu policy…

It's a bug in the linux kernel that was introduced in 4.18 and later fixed. You might be ok if you're on a later or newer version.

The symptom primarily seems to manifest that you get heavy throttling even though you haven't actually gotten to your cpu limit yet.

If you're just seeing heavy throttling AND its pegged at the limit, you haven't necessarily hit the issue and should raise the limit first and observe.

Also don't forget to eliminate other possibilities. We initially thought we were experiencing this issue and later discovered the app was just memory constrained and extremely heavy GC during certain operations was causing the throttling.

Re: Kubernetes 1.18

#58

Post by snupples »

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 not really that complex. It has primitives that cover a huge number of needs, so it can be complex when needed to solve complex problems, or simple when you're solving a simple problem.

I get the feeling people glance over the documentation and assume that you MUST use every single feature. Most of the features are only there when you need them for supporting advanced use.

Re: Kubernetes 1.18

#59

Post by gigatexal »

dragonsh wrote: post #54
gigatexal wrote: post #53

Earlier quoted context omitted.

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

I don't need to fight it, I am not looking for a job and follow the herd mentality. My own startup is pretty happy with Guix and related infrastructure on bare-metal, it works well for us and we can still stand on shoulders of giants who have done much better job in managing large distributed infrastructure.

That’s awesome. I’m not evangelizing it or saying you should use it as I did say “where appropriate” and at your startup it doesn’t seem appropriate.

There are probably 10x more engineers that have experience with k8s than with guix though so ... perhaps that could be a factor though not a reason to change out the infra completely.

Re: Kubernetes 1.18

#60

Post by glass_of_water »

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?
Post reply on HN