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

101–110 of 194 posts

Re: K3s – Lightweight Kubernetes

#101

Post by asark »

omeid2 wrote: post #49
detaro wrote: post #4

Looks quite interesting for small setups, curious to read more about the limitations (E.g. " Added sqlite3 as the default storage mechanism. etcd3 is still available, but not the default. " - what availability promises can this make?)

In terms of etcd3 vs sqlite3, it is as reliable as most airplane systems that depend on it. https://www.sqlite.org/famous.html I think the "high availability by redundancy" story is oversold.

> I think the "high availability by redundancy" story is oversold.

More generally, an awful lot of systems that'd be fine with a SQL mirror (non-failover), some real backups on top, and a restore-from-backup event every 3-5 years, plus the occasional 1hr maintenance window, are instead made "HA" and "redundant" at 10+x the ops cost and, unless very well done, with even more down-time anyway because they're so damn complex.

Re: K3s – Lightweight Kubernetes

#102

Post by arcticfox »

tecleandor wrote: post #39

I've been laughing myself of for some minutes, not because the project is uninteresting (I'll be testing it next week on ARM, probably), but because I've decided to call this "Kubernetres" (Being 'TRES' three in Spanish)

That is amazing branding for the Spanish / Portuguese market. Well done.

Re: K3s – Lightweight Kubernetes

#104

Post by comma_at »

cdoxsey wrote: post #92
Jedi72 wrote: post #81

Earlier quoted context omitted.

I am not talking about Go. I dont care what your language is, the true underlying reasoning for your engineering choices is independent of language. It just so happens that these problems have been around for ~30 years, and there has been significant progress in developing tooling to face them, in the domains that the BEAM languages sphere of influence. Just like how Ecto, despite being a great tool, does not free us…

I'm not afraid of specialized tools. For example I've used RabbitMQ which I believe is written in Erlang. We run it in Kubernetes in both our CI environment and locally so we can use the same configuration for both. It runs a dozen microservices and saves us a lot of devops time. In our CI environment it's nice for a developer to roll out a new copy of the services from a different branch for testing, and because of…

I think (s)he was talking about BEAM. Using RabbitMQ makes no difference if you're not programming in Erlang. If you look at the BEAM VM you will see isolated processes, supervisors, restart strategies etc. Wikipedia[1] lists Erlang's runtime system characteristics: "Distributed, Fault-tolerant, Soft real-time, Highly available, non-stop applications, Hot swapping, where code can be changed without stopping a system." Does that ring any bells?

[1] https://en.wikipedia.org/wiki/Erlang_(programming_language)

Re: K3s – Lightweight Kubernetes

#105

Post by jimmy1 »

johnmarcus wrote: post #86
Jedi72 wrote: post #81

Earlier quoted context omitted.

I am not talking about Go. I dont care what your language is, the true underlying reasoning for your engineering choices is independent of language. It just so happens that these problems have been around for ~30 years, and there has been significant progress in developing tooling to face them, in the domains that the BEAM languages sphere of influence. Just like how Ecto, despite being a great tool, does not free us…

When I came across Erlang last year at a new company, I thought it was interesting how many problems Erlang solved that were also in Kubernetes. Self registering named services, processes that crash and restart automatically, health checks, etc. Unfortunately to use all those features the services needed to be written in Erlang of course, which isn't bad in itself, but unfortunately not the reality in todays multi-li…

"Who cares that these problems are solved in Erlang/BEAM if hardly anyone is writing end user software in Erlang/BEAM/Elixir", basically.

My number one reason for not using Erlang is lack of static typing. Dynamic type systems are great for small teams, not so great for "enterprise-wide" development. (I know this horse has been beaten to death here, trust me, I have heard the arguments for/against millions of times, I remain unconvinced).

Also the answer to this question is interesting to me as well http://erlang.org/pipermail/erlang-questions/2008-October/03... -- (granted this is from Oct 2008) apparently if you were to attempt to add static type checking in Erlang, it would have to fundamentally change some of these benefits erlang brings such as message passing and handling process death. Haven't been part of the erlang scene for a while, but would be interested to hear a rebuttal to that.

Re: K3s – Lightweight Kubernetes

#106

Post by jpeeler »

rcarmo wrote: post #70

This is very nicely done. It annoys me a bit to have to set up a registry and have a build cycle prior to actually deploying things, but gitkube might help there...

I hadn't heard of gitkube before. These blog posts helped me compare and contrast with similar solutions I had heard of (mainly skaffold and draft): https://blog.hasura.io/draft-vs-gitkube-vs-helm-vs-ksonnet-v... https://kubernetes.io/blog/2018/05/01/developing-on-kubernet...

Re: K3s – Lightweight Kubernetes

#107

Post by cdoxsey »

comma_at wrote: post #104
cdoxsey wrote: post #92

Earlier quoted context omitted.

I'm not afraid of specialized tools. For example I've used RabbitMQ which I believe is written in Erlang. We run it in Kubernetes in both our CI environment and locally so we can use the same configuration for both. It runs a dozen microservices and saves us a lot of devops time. In our CI environment it's nice for a developer to roll out a new copy of the services from a different branch for testing, and because of…

I think (s)he was talking about BEAM. Using RabbitMQ makes no difference if you're not programming in Erlang. If you look at the BEAM VM you will see isolated processes, supervisors, restart strategies etc. Wikipedia[1] lists Erlang's runtime system characteristics: "Distributed, Fault-tolerant, Soft real-time, Highly available, non-stop applications, Hot swapping, where code can be changed without stopping a system.…

So you're suggesting we use BEAM instead of Kubernetes?

So just rewrite all our code in Erlang, including off the shelf products we didn't write?

Then use some other technology to deploy the software, configure the machine, come up with a way to do service discovery, attach block devices to nodes, and automatically provision new machines based on resource usage?

It doesn't make sense yet it's seemingly repeated on every thread about Kubernetes.

The Erlang community should celebrate technologies like Kubernetes, Mesos, or any other number of resource scheduling systems because they're finally the industry taking seriously the problems addressed by Erlang.

Re: K3s – Lightweight Kubernetes

#108

Post by monstrado »

omeid2 wrote: post #49
detaro wrote: post #4

Looks quite interesting for small setups, curious to read more about the limitations (E.g. " Added sqlite3 as the default storage mechanism. etcd3 is still available, but not the default. " - what availability promises can this make?)

In terms of etcd3 vs sqlite3, it is as reliable as most airplane systems that depend on it. https://www.sqlite.org/famous.html I think the "high availability by redundancy" story is oversold.

Interesting enough, FoundationDB currently uses sqllite's storage engine for persistence.

Re: K3s – Lightweight Kubernetes

#109

Post by pritambaral »

newaccoutnas wrote: post #98
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.

I think that's the first time I've seen anyone advocate cloudformation above anything.

I cannot read what your parent says as an advocation for cloudformation, let alone above anything; only that sth is as bad as cloudformation.

Re: K3s – Lightweight Kubernetes

#110

Post by philips »

johnmarcus wrote: post #82

"Added sqlite3 as the default storage mechanism. etcd3 is still available, but not the default." I want to use and support this product for this reason alone. Etcd was always an un-necessary complexity added for god knows what reason. Later cluster management solutions have abstracted etcd creation and management away (thankfully), but it's always irksome that it is there. Thank you to the K3s development team for ta…

Alternatively the K3s authors could have embedded a single node etcd process into Kubernetes using the embed package instead of introducing sqlite.

https://godoc.org/github.com/etcd-io/etcd/embed

This is something the Kubernetes community might consider as well.

Post reply on HN