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

Domesticating Kubernetes

blog.quickbird.uk

Post reply on HN
Print view View original

31–40 of 100 posts

Re: Domesticating Kubernetes

#31

Post by reaktivo »

sdan wrote: post #2

I can attest to RPI i/o speed: its horrible. Combined with the fact that I have to build Docker containers on the RPIs themselves(because of arm), its more of a hassle than a cool add-on (to be clear I'm running Docker Swarm in a way that isn't too different from the setup of OP). Only reason I can see RPIs in kubernetes is if you're exclusively using ARM everywhere and/or are running some distributed cluster among d…

This is not much of a problem if you switch out of the 32bit Raspbian. Most images will work out of the box on ARM64

Re: Domesticating Kubernetes

#32

Post by wlll »

sdan wrote: post #2

I can attest to RPI i/o speed: its horrible. Combined with the fact that I have to build Docker containers on the RPIs themselves(because of arm), its more of a hassle than a cool add-on (to be clear I'm running Docker Swarm in a way that isn't too different from the setup of OP). Only reason I can see RPIs in kubernetes is if you're exclusively using ARM everywhere and/or are running some distributed cluster among d…

Is there an RPi alternative (ie. similar size, form etc.) that has better IO/Network speed?

I used RPis for my robot (https://sendc.at/dl/Kjjbt3dij6T733YgWsyv3p3Vv5GPGKO1q5IEFStV...) with daughter boards for motor control) and they wre pretty convenient, but never really considered running anything server-like on them because they have reportedly woeful network performance.

Re: Domesticating Kubernetes

#33

Post by pc86 »

vetinari wrote: post #27
davestephens wrote: post #17

Earlier quoted context omitted.

Few things to do: - specify a LAN IP for your ingress controller so it doesn't change. - Use ddwrt/dnsmasq to point *.k8s.myhomenetwork.local to said IP Once that's configured, you just configure the ingress hostname on services as you would "normally".

Also - do not use .local tld. It is a reserved one (RFC6762), for mDNS/Bonjour: > This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6 addres…

So what breaks if you use "*.[lastname].local" for your home network?

Re: Domesticating Kubernetes

#34

Post by tachion »

jimmcslim wrote: post #30
tachion wrote: post #19

Earlier quoted context omitted.

That's exactly what I meant. I know how to do it myself, but then again I'm not the target for these articles, but when I read them with the mindset of someone who is supposed to have a use of them, that's always the big missing bit for me.

Did davestephen's comment help though? Apart from suggesting a .local domain... that's a bad idea, try .lan instead. Then you could type (for Plex, for example) plex.k8s.lan Maybe we need the equivalent of traefik for DNS? https://news.ycombinator.com/item?id=23040478

I know how to solve this problem, so I wasn't commenting on his comment, but rather on the fact that none of these tutorials so far solve this problem for new users that they target.

Aside from that, I don't think what he proposes is a great solution, because what we'd need is the automated way for deployments to get that DNS created (or announced) for their IP when they get it or when it changes. Having it done manually and being static is vastly different in usability from k8s does with ingress/cloud controllers.

Re: Domesticating Kubernetes

#35

Post by 411111111111111 »

jimmcslim wrote: post #30
tachion wrote: post #19

Earlier quoted context omitted.

That's exactly what I meant. I know how to do it myself, but then again I'm not the target for these articles, but when I read them with the mindset of someone who is supposed to have a use of them, that's always the big missing bit for me.

Did davestephen's comment help though? Apart from suggesting a .local domain... that's a bad idea, try .lan instead. Then you could type (for Plex, for example) plex.k8s.lan Maybe we need the equivalent of traefik for DNS? https://news.ycombinator.com/item?id=23040478

Dns is part of stock k8s. It usually runs on the 10th ip of the services network.

It's the first service that goes up after you've initialized the cluster and initially serves only internal requests.

Nothing stops you from pointing the matching lookup zone to the internal dns of k8s, however. I've done it before and it worked great for lan requests.

If you want to expose it to the internet however, an automatically configured dns is probably not what you want, unless you actually have a public ip range to use with said services. In that case, the original comment makes more sense and you'd just add a wildcard dns to your ingress controller, which can be traefic or whatever else you want

Re: Domesticating Kubernetes

#36

Post by dabeeeenster »

wlll wrote: post #32
sdan wrote: post #2

I can attest to RPI i/o speed: its horrible. Combined with the fact that I have to build Docker containers on the RPIs themselves(because of arm), its more of a hassle than a cool add-on (to be clear I'm running Docker Swarm in a way that isn't too different from the setup of OP). Only reason I can see RPIs in kubernetes is if you're exclusively using ARM everywhere and/or are running some distributed cluster among d…

Is there an RPi alternative (ie. similar size, form etc.) that has better IO/Network speed? I used RPis for my robot ( https://sendc.at/dl/Kjjbt3dij6T733YgWsyv3p3Vv5GPGKO1q5IEFStV... ) with daughter boards for motor control) and they wre pretty convenient, but never really considered running anything server-like on them because they have reportedly woeful network performance.

I have this https://www.hardkernel.com/shop/odroid-n2-with-4gbyte-ram/

It's pretty powerful for the cost and has no fan etc. Arm64.

Re: Domesticating Kubernetes

#37

Post by vetinari »

pc86 wrote: post #33
vetinari wrote: post #27

Earlier quoted context omitted.

Also - do not use .local tld. It is a reserved one (RFC6762), for mDNS/Bonjour: > This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6 addres…

So what breaks if you use "*.[lastname].local" for your home network?

On zeroconf aware systems, it is still expected to be resolved via multicast; service discovery works by looking up srv/ptr/txt records on __$service.__$protocol.$hostname.local.

How it will behave will depend on your specific stack. Zeroconf aware (Macs, iOS devices, Linux with Avahi - i.e. most modern distributions) one will use multicast, zeroconf unaware (Windows) will use your DNS resolver. Devices (printers, etc) are a toss of a coin.

Re: Domesticating Kubernetes

#38

Post by [deleted] »

pc86 wrote: post #33
vetinari wrote: post #27

Earlier quoted context omitted.

Also - do not use .local tld. It is a reserved one (RFC6762), for mDNS/Bonjour: > This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6 addres…

So what breaks if you use "*.[lastname].local" for your home network?

[deleted]

Re: Domesticating Kubernetes

#39

Post by [deleted] »

pc86 wrote: post #33
vetinari wrote: post #27

Earlier quoted context omitted.

Also - do not use .local tld. It is a reserved one (RFC6762), for mDNS/Bonjour: > This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6 addres…

So what breaks if you use "*.[lastname].local" for your home network?

[deleted]

Re: Domesticating Kubernetes

#40

Post by rb808 »

I've given up running my own k8s at home a couple of times. It does seem to be getting easier, but then upgrading and maintaining breaks me again. + the other stuff like running your own container registry. Then with new centos podman breaks everything that worked OK in docker. I hate this stuff, so many problems its worth ignoring the whole stack.
Post reply on HN