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

K3s – Lightweight Kubernetes

k3s.io

Post reply on HN
Print view View original

171–180 of 194 posts

Re: K3s – Lightweight Kubernetes

#171

Post by MediumD »

rhizome31 wrote: post #30
MediumD wrote: post #9

Earlier quoted context omitted.

If you need to distribute containers on a handful of nodes, kubernetes is great (and far better than Docker swarm imho). However, most small businesses probably don't need to have a microservice setup and can simply deploy a simple monolith while they focus on getting their business off the ground.

Thank you. I was thinking that maybe swarm mode would be simpler to set up and maintain. Just to give more context, our use case is spawning Jupyter notebook in containers using JupyterHub and DockerSpawner so that each data scientist gets a personal ready-to-use environment to work with. With 4 data scientists we're beginning to reach the limits of the largest instance provided by our cloud provider and we're expect…

Gotcha. Yeah, I would much rather use a managed k8s service over deploying and maintaining my own. GCP's GKE has been great for us so far and very reasonably priced.

Re: K3s – Lightweight Kubernetes

#172

Post by xur17 »

farisjarrah wrote: post #169
xur17 wrote: post #158

Earlier quoted context omitted.

I really want to do this as well - we've just started looking at minikube for our group, and I'd love to use k3s instead, but does anyone know if it works on OSX? I was able to get a cluster running on my laptop in under a minute, which is pretty amazing.

Have you seen or used Microk8s ? Seems like it might be what you are looking for. Can be installed and removed via snap package too

Microk8s looks interesting as well, but it doesn't support osx as far as I can tell.

Re: K3s – Lightweight Kubernetes

#173

Post by tlynchpin »

Jedi72 wrote: post #29

"Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang." - Virding's Law

Erlang is a terrific platform, but it isn't very accessible to the wider population.

Timely, here's antirez on this topic when Redis was announced on HN ten years ago [0]:

> There are a lot of projects similar to Redis in Erlang actually: http://www.metabrew.com/article/anti-rdbms-a-list-of-distrib...

> Apart from speed what I like of C for this kind of projects is the self-contain-ness and the fact that most developers that may help in the development are probably able to read/write C but not Erlang.

[0] https://news.ycombinator.com/item?id=494903

Re: K3s – Lightweight Kubernetes

#174

Post by Ramiro »

xur17 wrote: post #156
buckhx wrote: post #112

Would love this or something similar for local development. Currently using the Docker for Mac k8s and it shreds my machine and end up with an hour of battery life. Had similar experience with minikube.

I would as well. Curious if anyone has tried this for local dev. Also curious if this can run on osx.

I tried it on my mac with the docker-compose from master and works pretty well.

Re: K3s – Lightweight Kubernetes

#176

Post by sliken »

peterwwillis wrote: post #150
sliken wrote: post #77

Earlier quoted context omitted.

Dunno. I've know several business owners that didn't take credit cards until recently, and even then only did so because the newer companies have significantly lowered the investment cost. Maybe you don't consider small family owned restaurants "real". Seems like there's an opportunity for a cheap 3 node cluster, sold as a value add to businesses and supported a platform that application writers could target. They mi…

"Cluster" doesn't really square with "small business". Like, why have 3 nodes? HA? They're all probably plugged into the same power run and switch and breathing the same A/C. They're not actually redundant but they are more complicated. So it makes no sense unless you have strangely huge/complicated computational requirements.

Why not? Small business can lose significant money from a few hours of downtime and support that's onsite within an hour is quite expensive.

I'm not thinking cluster for performance, just for HA.

For small business why not 3 x Raspberry Pi to enable as much functionality as possible without network and/or power? A cheap UPS would likely run a few Pi for days. Chick-fil-a (3 NUC in a k8s cluster) seems pretty proud of their setup, why not something similar for any similar size restaurant? 3x Pi for smaller businesses seems like a good fit.

Oh, and a Pi cluster isn't going to need any more AC than a human, even if it's uncomfortable. I have one in my attic and it regularly gets above 110 in the summer, no problems so far.

If the network is out, have the Pi fall over to WAN, this is pretty common these days. Some consumer routers support this (insert a sim car), and it's fairly common for raspberry Pis used for home security to support similar. Handling credit card transactions over WAN is reasonably practical... even falling over to a modem+POTS could do for an emergency.

So between UPS (even UPS + solar + battery would be reasonable for a Pi) and fallover to WAN or modem a 3 way cluster could help keep business up during power outages, storms, earthquakes, fires, and of course node failures.

Question is can the right combination of hardware standardization, software standardization, support, and application store get together to enable chick-fil-a like functionality at a price point acceptable to small businesses?

Re: K3s – Lightweight Kubernetes

#177

Post by joseph8th »

comboy wrote: post #10

Not trying to be snarky, just a sincere question - why would you use kubernetes for something like IoT?

We use it to orchestrate agents, most of which, but not all, tunnel into VPN concentrators scattered across the globe to monitor and control remote devices. Admittedly ours is in the M2M IoT space for now (Digital Cinema) -- we don't deploy our own sensor network (yet) though our agent could broker that integration as well.

After toying with k8s, we realized just how much tinker time our current docker-n-script approach takes to optimize and scale optimally. We're close to moving to k8s after almost a year of on-again/off-again dev and I'm very excited to roll it out. Not as excited as DevOps, maybe, as it's going to lift a lot of weight off their shoulders.

TL;DR: IoT means different things in different industries.

Re: K3s – Lightweight Kubernetes

#178

Post by pcr0 »

013a wrote: post #114
sheeshkebab wrote: post #87

Earlier quoted context omitted.

> great K8S API, that Swarm lacks Hmm... nothing against k8s, but it’s deployment api is an abomination on par with aws cloudformation. You need teams of yaml engineers to manage these things.

https://twitter.com/kelseyhightower/status/93525292372179353... That's the exact problem Rancher itself is trying to solve, and it does a pretty fantastic job at it. Though suggesting its "on par" with CloudFormation suggests that you either know a ton about CloudFormation (anything becomes second nature if you're skilled in it) or you don't know much about either of them. Kubernetes isn't that bad.

It's definitely bad when you have thousands of lines of YAML configuration to maintain.

On the other hand, a thought out declarative language like Hashicorp's HCL is much saner thanks to IDE code completion/refactoring and static typing.

Re: K3s – Lightweight Kubernetes

#179

Post by geofft »

johnmarcus wrote: post #91
geofft wrote: post #84

Earlier quoted context omitted.

AIUI it gets you away from a single point of failure, right? Unless you have a reliable NFS server (and non-SPOF NFS servers are rare and pricy), running k8s on SQLite sounds like you can only have one master. Of course that's totally fine for many k8s deployments and might even increase reliability for some use cases, but still, moving from a distributed system to a local one is a significant change.

meh. Practically speaking, we're talking about a single point of disk failure - which certainly happens but at a rate that is sufficiently low. Plus, the actual amount of data stored is tiny, you can replicate it in seconds. Amazon has solutions for this if it's truly of concern, I would guess google does as well. IMHO, the operation of etcd - and the fact the data became unreadable if you lost quorum - was a much hi…

Disk failure happens quite frequently for me at scale, but so do other things like RAM going bad or network cards dying or entire mainboards just acting weird or top-of-rack switches silently dropping packets because of memory corruption (all of these have happened to machines I'm responsible for in the last six months). Again I think this is a matter of scale. If you've got enough machines that disk failure is a concern, you can also run a 9-node etcd cluster and have a big enough pager rotation that keeping 5 of them up 99.999% if not 100% of the time isn't a challenge. If you have less than a rack of machines and you're not at the point where you're worried about having a SPOF in your network switches or power supplies, running etcd a bunch of overhead for a problem you don't have and you are genuinely better served by a robust non-distributed system whose availability is the availability of your hardware.

Re: K3s – Lightweight Kubernetes

#180

Post by pas »

pcr0 wrote: post #178
013a wrote: post #114

Earlier quoted context omitted.

https://twitter.com/kelseyhightower/status/93525292372179353... That's the exact problem Rancher itself is trying to solve, and it does a pretty fantastic job at it. Though suggesting its "on par" with CloudFormation suggests that you either know a ton about CloudFormation (anything becomes second nature if you're skilled in it) or you don't know much about either of them. Kubernetes isn't that bad.

It's definitely bad when you have thousands of lines of YAML configuration to maintain. On the other hand, a thought out declarative language like Hashicorp's HCL is much saner thanks to IDE code completion/refactoring and static typing.

K8s YMLs are the baseline, and there are projects to have a lot more ergonomic description interface. They are ugly because they are also static typed and very extensible.

YAML is 1-1 mappable to HCL - because both map to JSON, but the Hashicorp interface seems nicer because it's simpler.

Post reply on HN