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

Canonical introduces high-availability Micro-Kubernetes

zdnet.com

Post reply on HN
Print view View original

111–118 of 118 posts

Re: Canonical introduces high-availability Micro-Kubernetes

#111

Post by raffraffraff »

merb wrote: post #17
zemo wrote: post #13

writing one application was hard so instead let's assume writing lots of tiny applications will be easier (???) but isolating them is hard so let's put them in containers but running containers is complicated so we need orchestration managers like kubernetes or something but running those things is too hard for someone whose job isn't to run kubernetes for a living so microk8s or minikube or k3s or whatever? that's t…

everybody who doesn't writes thousands of shell scripts/ansible/puppet whatever stuff to emulate a small version of kubernetes

Which is exactly what I did in my previous job before Kubernetes existed. When you're cobbling things together yourself you can leave features out of the design of your deployment / orchestration system. That is a blessing and a curse. A lot of the time you just end up ducktaping that feature on later because "oh shit, it keeps breaking". Eventually your "simpler" system is just as complex a design, but the system has lots of major flaws:

* It doesn't work as well

* Nobody outside your company has heard of it

* Most of the code is once-off hacky scripts that nobody really maintains

* Breakages will occur when underlying dependencies get upgraded when you patch your OS.

I'll even wager that nobody inside your company completely understand how it works. And when it breaks, you are 100% on the hook for it. There's no chance of official documentation or training, and no point asking for help on stackoverflow.

Re: Canonical introduces high-availability Micro-Kubernetes

#112

Post by tryauuum »

emptysongglass wrote: post #86
tryauuum wrote: post #29

Earlier quoted context omitted.

we are using this thing — http://archive.ubuntu.com/ubuntu/ubuntu/dists/focal/main/ins... , it is loaded with PXE. It doesn't put a "customized image of some sort" on servers, it literally iterates through installer steps with the autoanswers provided by preseed file. You might say that it is customized since we wrote a preseed file. Well maybe, but it's not a "customized image". Also we didn't write any specific cod…

You may be in for a shock using Ubuntu Server 20.04 and later as it has switched to using cloud-init. Preseed files no longer work.

They do work. Old installer is marked as legacy but still works.

Re: Canonical introduces high-availability Micro-Kubernetes

#113

Post by bayindirh »

enriquto wrote: post #83
bayindirh wrote: post #19

Earlier quoted context omitted.

> I just don't trust Canonical much... They lost me when I've tried their ubuntu server when I was lazy one day and greeted with their Landscape advertisement in the MOTD display. Then I installed armbian's ubuntu version because Debian version was not ready and found out that MOTD was downloaded from web every time I log in. Add analytics (now opt-in), forcing snaps and their silent-ish efforts to monopolize the lan…

Putting a single commercial, once, on the MOTD file is a sure way to tarnish the reputation of a whole distribution and its derivatives forever.

It's more of a last straw than a sole reason to be honest. There's a lot of stuff Canonical is doing which can be considered as embrace, extend and extinguish.

It's funny when a corporation uses tactics of another corporation it wants to beat.

[0]: https://bugs.launchpad.net/ubuntu/+bug/1

Re: Canonical introduces high-availability Micro-Kubernetes

#114

Post by bayindirh »

snicker7 wrote: post #92
enriquto wrote: post #83

Earlier quoted context omitted.

Putting a single commercial, once, on the MOTD file is a sure way to tarnish the reputation of a whole distribution and its derivatives forever.

The worst thing about Linux are its users.

Care to elaborate?

Re: Canonical introduces high-availability Micro-Kubernetes

#115

Post by bayindirh »

elderbarry wrote: post #106
bayindirh wrote: post #19

Earlier quoted context omitted.

> I just don't trust Canonical much... They lost me when I've tried their ubuntu server when I was lazy one day and greeted with their Landscape advertisement in the MOTD display. Then I installed armbian's ubuntu version because Debian version was not ready and found out that MOTD was downloaded from web every time I log in. Add analytics (now opt-in), forcing snaps and their silent-ish efforts to monopolize the lan…

It’s easy enough to configure motd to pull your own notices for a company, and useful too. Nothing there seems particularly weird to me in this day and age, and Ubuntu has a much better track record of actual security maintenance over the long term.

> Ubuntu has a much better track record of actual security maintenance over the long term.

Debian has 24 hour security fixes for 15+ years. It also supports "OldStable" in terms of security & backports. For some time it also has "Long Term Support" teams which supports older releases.

Debian is "the original" install & forget distro. Ubuntu has some commercial sauce over it but, unless you have a special need, Debian can handle everything you throw at it.

We have so much servers so that we sometimes forget some of our background service servers' and they hum all-along with all security updates applied.

Re: Canonical introduces high-availability Micro-Kubernetes

#116

Post by dhagz »

e12e wrote: post #110
dhagz wrote: post #93

Earlier quoted context omitted.

My employer has over 2000 clusters running k3s (I'm on the team that manages them), it's been...okay. We're on an old version though, so a lot of the k3s-specific issues we're running into are mostly fixed in more recent releases. The issues we run into more often are network or power related than k3s itself. Sometimes with the OS image the devices are running.

> My employer has over 2000 clusters running k3s Oh wow.. Why so many clusters, and what kind of resources per cluster? Are you running 100 000s of physical servers? Or are you just using k3s over three physical nodes as a way to achieve hardware redundancy and rolling hardware replacement?

We're providing a "smart kitchen" solution in restaurants.

Each restaurant has three Intel NUCs, so a little over 6K-7K devices. We're using k3s partly for the hardware redundancy, and partly for the ease of managing the services running at the edge - there's a local OAuth provider, MQTT server, along with some other applications that need to be up a majority of the time.

There's a cloud component to all of the software running at the edge as well, and since that's run on k8s, we wanted something similar but more lightweight at the edge.

Re: Canonical introduces high-availability Micro-Kubernetes

#117

Post by e12e »

dhagz wrote: post #116
e12e wrote: post #110

Earlier quoted context omitted.

> My employer has over 2000 clusters running k3s Oh wow.. Why so many clusters, and what kind of resources per cluster? Are you running 100 000s of physical servers? Or are you just using k3s over three physical nodes as a way to achieve hardware redundancy and rolling hardware replacement?

We're providing a "smart kitchen" solution in restaurants. Each restaurant has three Intel NUCs, so a little over 6K-7K devices. We're using k3s partly for the hardware redundancy, and partly for the ease of managing the services running at the edge - there's a local OAuth provider, MQTT server, along with some other applications that need to be up a majority of the time. There's a cloud component to all of the softw…

Interesting. Do you happen to have a blog post or something discussing how you arrived at that architecture?

Do you frequently see a nuc dying, but the cluster staying up?

Re: Canonical introduces high-availability Micro-Kubernetes

#118

Post by dhagz »

e12e wrote: post #117
dhagz wrote: post #116

Earlier quoted context omitted.

We're providing a "smart kitchen" solution in restaurants. Each restaurant has three Intel NUCs, so a little over 6K-7K devices. We're using k3s partly for the hardware redundancy, and partly for the ease of managing the services running at the edge - there's a local OAuth provider, MQTT server, along with some other applications that need to be up a majority of the time. There's a cloud component to all of the softw…

Interesting. Do you happen to have a blog post or something discussing how you arrived at that architecture? Do you frequently see a nuc dying, but the cluster staying up?

Yeah, there are some posts out there. I'll have to find them and edit them in.

Yes, in fact - we've seen clusters still running when two of the NUCs have disappeared from the cluster.

Post reply on HN