Het grote Kubernetes topic

[Douweegbertje]

Kubernetes. Waar moet je beginnen. Er zijn genoeg guides te vinden om met Kubernetes van start te gaan, toch zit er een massive learning curve om dit gedegen in een daadwerkelijke production environment te gaan draaien.

Dit topic is om discussies te voeren over Kubernetes. Dit is natuurlijk een ruim begrip omdat er niet alleen genoeg te praten valt over "hoe" je Kubernetes kan draaien/beheren, maar net zo goed "hoe" je het kunt gebruiken.

Wat is Kubernetes?

Even de inleiding vanuit wikipedia.

Kubernetes is een open-source containerorkestratie-systeem voor het automatiseren van de implementatie, schaling en beheer van applicaties. Het is oorspronkelijk ontworpen door Google en wordt nu onderhouden door de Cloud Native Computing Foundation.

Het doel is om een "platform te bieden voor het automatiseren van de implementatie, schaling en werking van applicatiecontainers in clusters van hosts". Het werkt met een reeks containerhulpmiddelen, waaronder Docker. Veel cloudservices bieden een Kubernetes-gebaseerd platform of infrastructuur als een service (PaaS of IaaS) waarop Kubernetes kan worden ingezet als een platform-leverende service. Veel leveranciers bieden ook hun eigen merk Kubernetes-distributies.

Lokaal Kubernetes draaien

Er zijn diverse manieren om lokaal Kubernetes te draaien. Vaak meer als "dev" c.q. "test" omgeving, dan dat je dit ook daadwerkelijk zo wilt gebruiken om echt zaken blijven te draaien op Kubernetes.

KIND: https://github.com/kubernetes-sigs/kind
Minikube: https://kubernetes.io/doc...ing-environment/minikube/
microk8s: https://microk8s.io/
k3s (hoewel ook prima in "prd" te draaien): https://k3s.io/

In de cloud - As a service

De meest bekende opties zijn:

Azure: Azure Kubernetes Service (AKS)
AWS: Amazon Elastic Kubernetes Service (EKS)
Google: Google Kubernetes Engine (GKE)

Natuurlijk zijn er nog veel meer aanbieders, zoals bij DigitalOcean, IBM, OVH, etc. Bekijk zelf goed wat de pro's/con's per platform zijn.

Zelf een cluster uitrollen

Ongeacht of je nu on-prem of in de cloud zit, is het prima mogelijk om zelf een cluster uit te rollen. On-prem heeft natuurlijk wel zijn uitdagingen als het gaat om storage, connectiviteit, HA, ingresses, en de lijst gaat door. Doch is dit prima uitvoerbaar. De bekendste "termen/tools" hiervoor zijn:

Kubeadm: https://kubernetes.io/doc...m/create-cluster-kubeadm/
kops: https://github.com/kubernetes/kops
kubespray: https://github.com/kubernetes-sigs/kubespray

Enterprise Kubernetes Platforms

Rancher: https://rancher.com/
Openshift: https://www.openshift.com/
En de Open Source variant van openshift is OKD: https://www.okd.io/

k8s/k3s op een Pi

github repo met veel informatie: https://github.com/alexellis/k3sup
https://blog.hypriot.com/...tes-raspberry-pi-cluster/

Communities

Op slack: https://slack.k8s.io/ - Hier is ook een #nl-users kanaal.
Dutch Kubernetes/Cloud-Native Meetup: https://www.meetup.com/Dutch-Kubernetes-Meetup/
#KubeCon + #CloudNativeCon https://events.linuxfound...on-cloudnativecon-europe/

Voor de iets meer die-hards die "echt een probleem" hebben is er ook de: https://www.meetup.com/Kubernetes-Support-Group/

Tools

kubectl - je bread and butter - https://kubernetes.io/docs/tasks/tools/install-kubectl/
kns - quick Kubernetes Namespace Switcher - https://github.com/blendle/kns
ktx - manage kubernetes cluster configs - https://github.com/heptiolabs/ktx

Goh, wat is je openingspost globaal/weinig informatie

Klopt!

Omdat als je letterlijk alles wilt vertellen, alle opties moet weergeven en alle details moet geven, je eerder een rack aan boeken benodigd hebt dan 1 simpele openingspost. In de basis staan hier nu wat linkjes. Dit kan prima worden uitgebreid naarmate het topic loopt. Zeker met jullie input!

[Voor 4% gewijzigd door Douweegbertje op 15-08-2020 13:25]

[g1n0]

Wellicht is https://rancher.com/ een leuke toevoeging voor beginners.

[Douweegbertje]

g1n0 schreef op dinsdag 2 juni 2020 @ 00:19:
Wellicht is https://rancher.com/ een leuke toevoeging voor beginners.

Ik heb een kopje erbij gezet m.b.t "Enterprise Kubernetes Platforms" - Persoonlijk vind ik rancher geen beginners dingetje (I could be wrong though!).

[reputatio]

In de trant van: Niet geschoten altijd mis, en om te beginnen met het stellen van vragen:
Ik ben bezig met het omzetten van een project op basis van containers naar Kubernetes. Moet te doen zijn, zou je zeggen. Dit project beheer ik zelf niet, maar is een open-source project van een bedrijf, project in kwestie: https://github.com/balena-io/open-balena.

Nu ben ik al tegen heel wat dingen aangelopen, die ik allemaal heb kunnen oplossen. Nu alleen het laatste, maar waarschijnlijk ook grootste probleem: Het bereiken van mijn eigen domein vanuit Kubernetes.

Ik gebruik DigitalOcean voor het beheren van Kubernetes en gebruik Ingress voor routing van subdomeinen. Nu praten de containers tegen elkaar via requests naar het domein. Voorbeeld: De VPN pod praat met de API via https://api.domein.com/. Alleen aangezien dit domein linkt naar de Kubernetes cluster via een LoadBalancer van DigitalOcean, en kubernetes rare iptable rules dan toepast, kan ik vanuit de VPN pod, de API pod niet bereiken.

Nu heb ik dit ook gevraagd in de issue zelf of hier een oplossing voor is, maar misschien dat mensen hier tegen hetzelfde probleem zijn aangelopen?

[Douweegbertje]

reputatio schreef op woensdag 17 juni 2020 @ 17:02:
In de trant van: Niet geschoten altijd mis, en om te beginnen met het stellen van vragen:
Ik ben bezig met het omzetten van een project op basis van containers naar Kubernetes. Moet te doen zijn, zou je zeggen. Dit project beheer ik zelf niet, maar is een open-source project van een bedrijf, project in kwestie: https://github.com/balena-io/open-balena.

Nu ben ik al tegen heel wat dingen aangelopen, die ik allemaal heb kunnen oplossen. Nu alleen het laatste, maar waarschijnlijk ook grootste probleem: Het bereiken van mijn eigen domein vanuit Kubernetes.

Ik gebruik DigitalOcean voor het beheren van Kubernetes en gebruik Ingress voor routing van subdomeinen. Nu praten de containers tegen elkaar via requests naar het domein. Voorbeeld: De VPN pod praat met de API via https://api.domein.com/. Alleen aangezien dit domein linkt naar de Kubernetes cluster via een LoadBalancer van DigitalOcean, en kubernetes rare iptable rules dan toepast, kan ik vanuit de VPN pod, de API pod niet bereiken.

Nu heb ik dit ook gevraagd in de issue zelf of hier een oplossing voor is, maar misschien dat mensen hier tegen hetzelfde probleem zijn aangelopen?

Ai, pittig vervelend issue inderdaad Ik ben bang dat je dit niet gaat oplossen zonder een workaround of whatever dirty fix. Tenminste totdat iemand zo'n issue oplost of DigitalOcean dezelfde dirty fix toegevoegd

Maar nu ben ik misschien gewoon heel simpel hoor, maar zou je dan niet ipv 'api.domein.com' een svc/api gebruiken en binnen je cluster blijven? Of is dat simpwel niet in te stellen? Dat zou potentieel je probleem kunnen oplossen.

Persoonlijk ben ik ook wel fan geweest van DigitalOcean. Ik heb er ook wel wat VPSjes gehad en k8s. Doch zou ik toch aanraden om dit puur bij een AWS / Google te doen. Mijn ervaring is dat ze toch iets volwassener zijn in de stack en alle meuk daaromheen. Als je de mogelijkheid hebt, zou ik toch echt een switch overwegen.

[reputatio]

Bedankt voor je antwoord!
Ik heb inderdaad gekeken naar services, maar alles gebruikt `https://subdomein.domein.com`, dus dit is eigenlijk niet te doen, totdat zij zelf een fix hebben voor Kubernetes. Dus dat is erg jammer...

Wat betreft switchen, ik ben erg tevreden over DigitalOcean op dit moment. Een switch naar AWS / Google zien wij in de toekomst voor ons, maar op dit moment voldoet DigitalOcean aan de eisen. Maar zal het in ieder geval in gedachte houden!

[Douweegbertje]

En nog wat nieuwe ontwikkelingen: https://rancher.com/press/suse-to-acquire-rancher/

Ik ben daar zelf niet heel content mee, maar we gaan het zien..

[TweakMDS]

reputatio schreef op woensdag 17 juni 2020 @ 17:02:
Nu heb ik dit ook gevraagd in de issue zelf of hier een oplossing voor is, maar misschien dat mensen hier tegen hetzelfde probleem zijn aangelopen?

Het is twee maanden geleden, dus wellicht heb je het al opgelost, of er op een andere manier overheen gestapt, maar één mogelijke richting zou een Egress / service mesh kunnen zijn. Istio heeft daar een prima oplossing voor, maar de leercurve is wat hoger, en je wil waarschijnlijk dan de hele istio stack als ingress en egress gebruiken.
Wellicht geeft dit een stap in de juiste richting. https://istio.io/latest/d...nt/egress/egress-gateway/

[Mars Warrior]

SndBastard schreef op zaterdag 15 augustus 2020 @ 11:17:
[...]
Het is twee maanden geleden, dus wellicht heb je het al opgelost, of er op een andere manier overheen gestapt, maar één mogelijke richting zou een Egress / service mesh kunnen zijn. Istio heeft daar een prima oplossing voor, maar de leercurve is wat hoger, en je wil waarschijnlijk dan de hele istio stack als ingress en egress gebruiken.
Wellicht geeft dit een stap in de juiste richting. https://istio.io/latest/d...nt/egress/egress-gateway/

Waarom zou dit een oplossing zijn voor het probleem eigenlijk? Normaal is een egress gateway louter bedoeld vanuit beveiliging zodat maar één node naar buiten mag in het cluster.

Verder heeft Istio inderdaad een behoorlijke hoge leercurve en is erg moeilijk te debuggen als het fout gaat. Voor mij de reden om Istio nooit te gebruiken.

[TweakMDS]

Mars Warrior schreef op zaterdag 15 augustus 2020 @ 11:35:
[...]

Waarom zou dit een oplossing zijn voor het probleem eigenlijk? Normaal is een egress gateway louter bedoeld vanuit beveiliging zodat maar één node naar buiten mag in het cluster.

Verder heeft Istio inderdaad een behoorlijke hoge leercurve en is erg moeilijk te debuggen als het fout gaat. Voor mij de reden om Istio nooit te gebruiken.

Nu je dit zo stelt heb ik denk ik het probleem ook verkeerd begrepen. Ik dacht dat het ging om toegang naar een API die buiten het cluster staat, met gebruik van de egress gateway kan je alles binnen je cluster min of meer zo organiseren dat ook externe resources binnen je cluster te benaderen zijn. Ik vond het overigens niet heel moeilijk te debuggen, maar de primaire use case van Istio egress is inderdaad meer vanuit voldoen aan security policies.

[redfox314]

Ik wilde nog een paar resources toevoegen.

Kubernetes met raspberry pies https://blog.hypriot.com/...tes-raspberry-pi-cluster/

Ik constateerde wel dat de master node een beetje zwaar is voor een pi 3B+ maar voor worker nodes kan het perfect.

Op een bepaald moment wil je gemakkelijk in je cluster komen:

Metallb laat je toe om gemakkelijk een blok ip adressen toe te kennen voor gebruik in je cluster en zal ook antwoorden op ARP requests https://metallb.universe.tf/

Misschien wil je toch een application gateway. Traefik doet dat. Het meest basis gebruik is zoals name based virtual hosts in Apache. Een bepaalde hostname routeerd naar een kubernetes pod. Bonus: traefik heeft LetsEncrypt support. Zowel http validatie als domain validatie zijn supported met een hele zoo aan domain providers built in.

https://containo.us/traefik/

Eigenlijk wil je al die services niet handmatig op je cluster installeren. Die yaml files zijn best ingewikkeld.

Helm is de apt of yum voor kubernetes. https://helm.sh/

Zowel metallb als traefik zijn beschikbaar als helm charts.
https://helm.sh/

[Douweegbertje]

redfox314 schreef op zaterdag 15 augustus 2020 @ 13:06:
Ik wilde nog een paar resources toevoegen.

Kubernetes met raspberry pies https://blog.hypriot.com/...tes-raspberry-pi-cluster/

Ik constateerde wel dat de master node een beetje zwaar is voor een pi 3B+ maar voor worker nodes kan het perfect.

Op een bepaald moment wil je gemakkelijk in je cluster komen:

Metallb laat je toe om gemakkelijk een blok ip adressen toe te kennen voor gebruik in je cluster en zal ook antwoorden op ARP requests https://metallb.universe.tf/

Misschien wil je toch een application gateway. Traefik doet dat. Het meest basis gebruik is zoals name based virtual hosts in Apache. Een bepaalde hostname routeerd naar een kubernetes pod. Bonus: traefik heeft LetsEncrypt support. Zowel http validatie als domain validatie zijn supported met een hele zoo aan domain providers built in.

https://containo.us/traefik/

Eigenlijk wil je al die services niet handmatig op je cluster installeren. Die yaml files zijn best ingewikkeld.

Helm is de apt of yum voor kubernetes. https://helm.sh/

Zowel metallb als traefik zijn beschikbaar als helm charts.
https://helm.sh/

Ik heb een kopje toegevoegd. Persoonlijk vind ik k3s geschikter om op een Pi te plaatsen. Daar staat nu ook een github repo van!

[Mars Warrior]

Douweegbertje schreef op zaterdag 15 augustus 2020 @ 13:26:
[...]


Ik heb een kopje toegevoegd. Persoonlijk vind ik k3s geschikter om op een Pi te plaatsen. Daar staat nu ook een github repo van!

Ik vind k3s sowieso veel geschikter om thuis te draaien dan k8s. K8s is een aardig waterhoofd als het gaat om informatie en resources. k3s maakt dat allemaal veel toegankelijker. Wie weet komt er ooit nog een k1s of k2s die de rest van het vet verwijderd

Als je in k3s de ingebouwde loadbalancer vervangt door metallb en Traefik 1 door Traefik 2, dan heb je een hele leuke combi waar redelijk wat over te vinden is.

En kom je van het veel eenvoudigere Docker / Docker Swarm af, dan kun je je compose files met Kompose omzetten naar die enorme resource files die Kubernetes nodig heeft...

Wil je lekker webbased apps deployen zonder veel moeilijke dingen dan is Kubeapps misschien wat voor je.

Of toch maar via de cli? Dan is Arkade een optie.

Natuurlijk hebben we ook nog Portainer - bekend van Docker (Swarm), en nu ook (bijna) beschikbaar op Kubernetes. Ook deze haalt heel wat van de complexiteit weg en maakt het aanpassen en deployen van apps en volumes een stuk eenvoudiger.

Voor gedistribueerde opslag is Piraeus een mooie nieuwkomer. Nou ja, nieuwkomer. Het is gebaseerd op het aloude drbd9 en tov andere oplossingen rete snel

Voor authorisatie / SSO kun je bijv. Authelia gebruiken. Kan samenwerken met Traefik (forward authentication) voor het beveiligen van al je apps, dus ook de apps die geen eigen login hebben. 2-factor en OTP behoren ook tot de mogelijkheden. Kun je nog echt redelijk veilig ook alles van buitenaf gebruiken...


En zo kun je nog wel ff doorgaan met mogelijkheden.

[Douweegbertje]

Mars Warrior schreef op zondag 16 augustus 2020 @ 12:23:
[...]

Ik vind k3s sowieso veel geschikter om thuis te draaien dan k8s. K8s is een aardig waterhoofd als het gaat om informatie en resources. k3s maakt dat allemaal veel toegankelijker. Wie weet komt er ooit nog een k1s of k2s die de rest van het vet verwijderd

Als je in k3s de ingebouwde loadbalancer vervangt door metallb en Traefik 1 door Traefik 2, dan heb je een hele leuke combi waar redelijk wat over te vinden is.

En kom je van het veel eenvoudigere Docker / Docker Swarm af, dan kun je je compose files met Kompose omzetten naar die enorme resource files die Kubernetes nodig heeft...

Wil je lekker webbased apps deployen zonder veel moeilijke dingen dan is Kubeapps misschien wat voor je.

Of toch maar via de cli? Dan is Arkade een optie.

Natuurlijk hebben we ook nog Portainer - bekend van Docker (Swarm), en nu ook (bijna) beschikbaar op Kubernetes. Ook deze haalt heel wat van de complexiteit weg en maakt het aanpassen en deployen van apps en volumes een stuk eenvoudiger.

Voor gedistribueerde opslag is Piraeus een mooie nieuwkomer. Nou ja, nieuwkomer. Het is gebaseerd op het aloude drbd9 en tov andere oplossingen rete snel

Voor authorisatie / SSO kun je bijv. Authelia gebruiken. Kan samenwerken met Traefik (forward authentication) voor het beveiligen van al je apps, dus ook de apps die geen eigen login hebben. 2-factor en OTP behoren ook tot de mogelijkheden. Kun je nog echt redelijk veilig ook alles van buitenaf gebruiken...


En zo kun je nog wel ff doorgaan met mogelijkheden.

Storage blijft volgens mij altijd gewoon wel "een dingetje"
Ik probeer over het algemeen puur cloud native te blijven (zie ook https://12factor.net/ 12 factor apps).

Ooit moest ik domweg iets met storage doen en toen had ik gekozen voor een Ceph cluster met Rook: https://rook.io/ - My 2 cents: dat is misschien wel de meest volwassen oplossing die je kan doen.

Maar je gaat dan al heel snel enorm veel complexiteit toevoegen. Ik raad dat niet aan als je "een dev" bent zonder storage ervaring

[Mars Warrior]

Douweegbertje schreef op zondag 16 augustus 2020 @ 12:48:
[...]


Storage blijft volgens mij altijd gewoon wel "een dingetje"
Ik probeer over het algemeen puur cloud native te blijven (zie ook https://12factor.net/ 12 factor apps).

Ooit moest ik domweg iets met storage doen en toen had ik gekozen voor een Ceph cluster met Rook: https://rook.io/ - My 2 cents: dat is misschien wel de meest volwassen oplossing die je kan doen.

Maar je gaat dan al heel snel enorm veel complexiteit toevoegen. Ik raad dat niet aan als je "een dev" bent zonder storage ervaring

Storage blijft het grote probleem met Dit soort gedistribueerde systemen. En veel van die oplossingen gaan uit van heel veel data en zijn daarmee inherent complex.

OpenEBS - https://openebs.io/ - schijnt nog een redelijk makkelijk te zijn ten opzichten van de anderen. Performance was niet enorm en jaar geleden maar schijnt nu verbeterd te zijn.

Als je niet oppast dan ben je langer bezig met het uitzoeken van Storage dan met het opzetten van je hele cluster met mooie leuke applicaties hier op wil draaien. Alles is ook nog echt in ontwikkeling, dus er is nog niet echt een duidelijke winnaar voor een klein thuis netwerk.

Sommige Storage voorbeelden gaan al uit van circa 30 nodes. Zie Bijv ChubaoFS.. Niet echt een leuk voorbeeld voor een thuissituatie om dingen uit te proberen en te leren.

[TweakMDS]

Mars Warrior schreef op zondag 16 augustus 2020 @ 12:23:
[...]
Ik vind k3s sowieso veel geschikter om thuis te draaien dan k8s.
[...]

Eens! Ik heb hier onder mijn bureau een bescheiden NUC staan met een i5-4200u, 16GB ram en een 256GB SSD.
Daarop staat Proxmox met een aantal simpele Alpine VM's. Daarop een 3-node K3s cluster en één "management server" waar ik al mijn helm scripts en docker vm's op kan maken.

Dat is relatief makkelijk op te zetten, draait als een speer, en zelfs met de relatief bescheiden resources kan het zo goed als alles draaien wat ik er tegenaan gooi (binnen redelijkheid).

Voor storage gebruik ik nu nog gewoon "local-path" van K3s, wat werkt, maar ik zou liever Longhorn gebruiken, maar daarvoor moest ik eerst nog wat uitzoeken met iSCSI, wat ik niet direct 100% werkend kreeg.

Verder wel metallb voor "echte" loadbalancer IP's, Traefik als ingress met letsencrypt op meerdere cnames etc.

Als er animo is om eens dieper op die setup in te gaan wil ik daar wel een uitgebreidere post (of misschien zelfs tweakblog) aan besteden. Vond het voor mezelf in het afgelopen jaar in ieder geval een mooie leerschool, naast de zaken die ik er werk-gerelateerd mee doe.

[Voor 3% gewijzigd door TweakMDS op 16-08-2020 13:43]

[Mars Warrior]

SndBastard schreef op zondag 16 augustus 2020 @ 13:42:
[...]
Eens! Ik heb hier onder mijn bureau een bescheiden NUC staan met een i5-4200u, 16GB ram en een 256GB SSD.
Daarop staat Proxmox met een aantal simpele Alpine VM's. Daarop een 3-node K3s cluster en één "management server" waar ik al mijn helm scripts en docker vm's op kan maken.

Dat is relatief makkelijk op te zetten, draait als een speer, en zelfs met de relatief bescheiden resources kan het zo goed als alles draaien wat ik er tegenaan gooi (binnen redelijkheid).

Dat is een leuke setup. Ook lekker praktisch
Die extra node vind ik wel slim bedacht om zo al je scripts en VM's te kunnen aanmaken.

Voor storage gebruik ik nu nog gewoon "local-path" van K3s, wat werkt, maar ik zou liever Longhorn gebruiken, maar daarvoor moest ik eerst nog wat uitzoeken met iSCSI, wat ik niet direct 100% werkend kreeg.

Dan zou ik toch eens kijken naar OpenEBS. Die kent ook een eigen "local path" en "local device" plugin, maar kun je ook configureren voor gedistribueerde storage. Is wel trager, maar dan gebruik je wel één provider, die ook nog eens kan omgaan met Velero als backup en vziw metrics kan leveren richting Prometheus als dat nodig is.

Verder wel metallb voor "echte" loadbalancer IP's, Traefik als ingress met letsencrypt op meerdere cnames etc.

Met Traefik 2 neem ik aan dan? Metallb en Traefik vind ik de noodzakelijke 'wijzigingen' in de standaard k3s distributie. Heel erg goed te gebruiken in een thuis situatie.

Als er animo is om eens dieper op die setup in te gaan wil ik daar wel een uitgebreidere post (of misschien zelfs tweakblog) aan besteden. Vond het voor mezelf in het afgelopen jaar in ieder geval een mooie leerschool, naast de zaken die ik er werk-gerelateerd mee doe.

Dat lijkt mij erg nuttig. Ik loop al even achter in mogelijkheden, maar zoek wel steeds naar de meest eenvoudige oplossingen, zodat dit ook goed is te onderhouden.

Plaatjes helpen ook overigens

En zoals ik al aangaf: mettallb en traefik vind ik absoluut nodig. Met de storage blijf ik vechten, al neig ik dus nu naar OpenEBS vanwege de flexibiliteit en support door Velero backup en S3 (Minio).

Verder wordt arm64 ook ondersteund, oftewel een RPI. Ook wel fijn als je een SSD oid in je RPI gebruikt. Longhorn doet vziw nog geen arm

[TweakMDS]

Mars Warrior schreef op zondag 16 augustus 2020 @ 19:34:
Dat is een leuke setup. Ook lekker praktisch
Die extra node vind ik wel slim bedacht om zo al je scripts en VM's te kunnen aanmaken.

Even wat losse reacties; losse VM gebruik ik inderdaad zodat ik op mijn workstation (waar windows 10 op staat) niet zoveel hoef te installeren, en omdat ik voor kubernetes gerelateerde zaken liever een linux commandline gebruik. Verder is het makkelijk om vanuit daar ook eventueel naar de k3s hosts te kunnen ssh-en.
Op mijn PC staat alleen Lens, wat ik wel kan aanraden om snel een port forward aan te maken (gewoon op de service klikken, en hij opent een browser incl. proxy) en om snel dingen te kunnen vinden.

Dan zou ik toch eens kijken naar OpenEBS. Die kent ook een eigen "local path" en "local device" plugin, maar kun je ook configureren voor gedistribueerde storage. Is wel trager, maar dan gebruik je wel één provider, die ook nog eens kan omgaan met Velero als backup en vziw metrics kan leveren richting Prometheus als dat nodig is.

Geïnspireerd door mijn eigen post heb ik vanmiddag in ieder geval iSCSI even gefixed, zowel een target op een nieuwe "fileserver" VM aangemaakt, en ik zag dat ik op mijn nas ook nog een iscsi volume had draaien, dus kan daar weer verder mee experimenteren.

Met Traefik 2 neem ik aan dan? Metallb en Traefik vind ik de noodzakelijke 'wijzigingen' in de standaard k3s distributie. Heel erg goed te gebruiken in een thuis situatie.

Ik gebruik nog altijd Traefik 1 voor de ingress, maar heb de servicelb bij installatie van k3s uitgezet, omdat ik metallb beter vind werken. Traefik 2 heb ik geprobeerd, maar omdat ik alles met Terraform installeer en Terraform CRD ondersteuning nog in alpha is ben ik maar even bij Traefik 1 gebleven. Werkt overigens op alle fronten prima.

Verder was ik van plan om voor mijn collega's (enkelen die wel interesse hebben maar nog niet heel erg in K8s begaan zijn) een aantal introductie topics te schrijven. Ik zal die in de komende weken eens in elkaar zetten en ook hier delen.
Ik zag het als een soort serie:

Deel 1: Installatie Proxmox.
Deel 2: Installatie van 3 Alpine VM's en K3s.
Deel 3: Installatie MetalLB, IP adressen en port forwarding op de router.
Deel 3B: Alles opzetten met Terraform.
Deel 4: Demo applicaties: node red, prometheus + grafana, iets zelf gemaakts via Github en Dockerhub.
Deel 5: Domeinnaam registratie en ingress met geautomatiseerd LetsEncrypt met tls-alpn-01 challenge (dus zonder poort 80 open op de router). Optioneel: A+ rating halen op ssllabs en LetsEncrypt via DNS challenge met wildcard certificate als de provider ondersteund is.

Edit: Er kan natuurlijk nog een hoop bij, zoals OpenEBS etc, maar qua research en puzzelen heeft me dit menig avond bezig gehouden (leuke hobby) en blijft het uitbreiden.

[Voor 3% gewijzigd door TweakMDS op 16-08-2020 20:07]

[johnkeates]

Voor een thuislab met hardware die je al hebt kan ik me wel voorstellen dat het zin heeft zelf met meerdere nodes of virtualisatie aan de slag te gaan, maar is het niet veel verstandiger om dat gewoon op AWS, GCP of zelfs Azure te doen? Kubernetes heeft vooral zin als je dynamiek en bestendigheid wenst, en dat werkt alleen als je onderlaag dat ook heeft (dus replicated object storage, block storage, dns, hosts enz).

[TweakMDS]

johnkeates schreef op zondag 16 augustus 2020 @ 20:11:
Voor een thuislab met hardware die je al hebt kan ik me wel voorstellen dat het zin heeft zelf met meerdere nodes of virtualisatie aan de slag te gaan, maar is het niet veel verstandiger om dat gewoon op AWS, GCP of zelfs Azure te doen? Kubernetes heeft vooral zin als je dynamiek en bestendigheid wenst, en dat werkt alleen als je onderlaag dat ook heeft (dus replicated object storage, block storage, dns, hosts enz).

Absoluut, ik heb ook werk-gerelateerd best een paar clusters op Azure draaien, en ééntje op AWS gehad.
Voor mij was de reden om het op mijn LAB-doosje te zetten meer om alles from scratch te bouwen, en daarmee véél beter te begrijpen wat alles doet, hoe het werkt, en wat te doen als het niet werkt.

Toen ik met Kubernetes begon leek alles extreem complex, en werd ik overdonderd door de terminologie. Door alles stap voor stap zelf te doen. Het is echt een lab simulatie, maar de opzet is redelijk productie-proof. Uiteraard crashed de hele boel als mijn SSD crashed, en ga ik fijn backups terug zetten, of spin ik alles op op een nieuw cluster. Ik heb ook geen meerdere masters, dat kan wel (deel 6?) maar vond ik niet echt nodig en gebruikt relatief veel CPU.

Wat ik er zelf leerzaam aan vond, is dat je gewoonweg met een aardappel server een volwaardig cluster op kan zetten, die zich hetzelfde gedraagt als een production-grade installatie. Daarmee heb ik nu wel de ins en outs geleerd die ik bij enkel gebruik van Azure of AWS misschien nog niet goed zou hebben begrepen.

[johnkeates]

Ik merk ook wel dat mensen soms te snel beginnen met 'maar wat bouwen' op een public cloud en dan niet snappen hoe het in elkaar zit met als resultaat dat problemen oplossen, architectuur doorzien of opbouwen en kostenbeheer gewoon niet goed gaat.

Hetzelfde met Helm bijv, als het werkt is het leuk, maar als je niet weet hoe je het zonder Helm zou doen ben eigenlijk een applicatiebeheerder en voor been basistaken toch snel overgeleverd aan de kennis en middelen van anderen. Lijkt me voor een productieomgeving niet wenselijk ;-) Maar puur alles altijd met de hand doen is ook weer het andere uiterste, dan kan je niet goed samen werken en spullen hergebruiken om je werk te versnellen.

Edit: leuke extra opties als mixed clusters zijn soms op de public clouds niet beschikbaar maar 'private' wel, dan kan je dus nodes mixen met x86, ARM en POWER en dan bijv. alle pod specs blokkeren met OPA als ze geen images hebben met alle nodige architecturen Heb het nog niet proberen te mixen met MIPS of RISC-V (heb nog niet gekeken of dat überhaupt kan - maar met cgroups2 support zou dat gewoon moeten kunnen). Een andere is de storage laag onderaan voorzien van Ceph, maar dat wil ik dan eigenlijk op een setje losse fysieke systeempjes doen voor de leuk. Voor is dat met DRBD of OCFS2 wel goed te doen, maar niet zo cool als Ceph + RADOS block devices. (onder aan de streep heeft die laagste laag weer niks te maken met Kube..)

[Voor 34% gewijzigd door johnkeates op 16-08-2020 20:40]

[Mars Warrior]

Ik hou het maar simpel met ketchup, oftewel https://github.com/alexellis/k3sup.

Met een paar commando’s heb je je k3s cluster in de lucht!

Verder heb ik zelf ook niks aan een public Cloud omdat ik er voornamelijk lokale dingen op draai zoals een stuk domotica. Dus ik kijk ook niet eens naar mogelijkheden in de Cloud.

[Voor 39% gewijzigd door Mars Warrior op 16-08-2020 22:21]

[johnkeates]

Mars Warrior schreef op zondag 16 augustus 2020 @ 22:10:
Ik hou het maar simpel met ketchup, oftewel https://github.com/alexellis/k3sup.

Met een paar commando’s heb je je k3s cluster in de lucht!

Verder heb ik zelf ook niks aan een public Cloud omdat ik er voornamelijk lokale dingen op draai zoals een stuk domotica. Dus ik kijk ook niet eens naar mogelijkheden in de Cloud.

Maar waarom draai je dan uberhaupt Kubernetes? Dan is er toch geen meerwaarde meer aan de extra componenten.

[Douweegbertje]

SndBastard schreef op zondag 16 augustus 2020 @ 20:17:
[...]


Absoluut, ik heb ook werk-gerelateerd best een paar clusters op Azure draaien, en ééntje op AWS gehad.
Voor mij was de reden om het op mijn LAB-doosje te zetten meer om alles from scratch te bouwen, en daarmee véél beter te begrijpen wat alles doet, hoe het werkt, en wat te doen als het niet werkt.

Toen ik met Kubernetes begon leek alles extreem complex, en werd ik overdonderd door de terminologie. Door alles stap voor stap zelf te doen. Het is echt een lab simulatie, maar de opzet is redelijk productie-proof. Uiteraard crashed de hele boel als mijn SSD crashed, en ga ik fijn backups terug zetten, of spin ik alles op op een nieuw cluster. Ik heb ook geen meerdere masters, dat kan wel (deel 6?) maar vond ik niet echt nodig en gebruikt relatief veel CPU.

Wat ik er zelf leerzaam aan vond, is dat je gewoonweg met een aardappel server een volwaardig cluster op kan zetten, die zich hetzelfde gedraagt als een production-grade installatie. Daarmee heb ik nu wel de ins en outs geleerd die ik bij enkel gebruik van Azure of AWS misschien nog niet goed zou hebben begrepen.

Even los van dat ik je setup helemaal tof vind, ik val over je productie-proof en production-grade
Naar mijn inziens gaat dat veel verder en komt er meer bij kijken.

[Mars Warrior]

johnkeates schreef op maandag 17 augustus 2020 @ 02:54:
[...]
Maar waarom draai je dan uberhaupt Kubernetes? Dan is er toch geen meerwaarde meer aan de extra componenten.

Ik draai nu een mix van meerdere Docker Swarms met ca 100 containers en nog traditionele VM's met daarin software geïnstalleerd. Ik wil dat nu allemaal gaan samenvoegen tot één k3s cluster.

Ik heb nu een aantal websites draaien, domotica (en dus mqtt, grafana, etc.), maar ook bijv. Bitwarden en Bookstack voor al mijn documentatie. Een aardig deel is nu (via Apache) extern beschikbaar. Een vreemde mix dus...

Voor thuis vond ik een paar jaar geleden Docker Swarm daarom het meest toepasselijke, maar nu met de komst van k3s en bijv. Kompose worden dingen steeds eenvoudiger voor een Kubernetes thuisserver omgeving .

Ik wil dan ook toe richting zoiets als in dit plaatje:


In de basis dus een enkele master (oud, maar zeer zuinig (4w idle) Fujitsu PCtje) met een aantal agents (draaiend in een VM, of baremetal op een NUC en een aantal RPI's).
De meeste containers zullen dedicated draaien omdat ze aan hardware hangen (CV Ketel, DSMR, Z-wave, Zigbee, Zonnepanelen, etc.), dus in de meeste gevallen is redundantie geen issue en kan ook de storage lokaal blijven (met backup natuurlijk).

K3s met daarbij Metallb, Traefik 2.x en bijv. OpenEBS voor de opslag vormen (denk ik) het hart van het cluster voor de meeste thuisservers. Welke containers/apps je vervolgens draait maakt dan niet meer uit omdat de basis er ligt.

Het centrale beheer - ook veilig van buiten met bijv. een extra laag door Authelia - vind ik erg fijn om te hebben. Ik tracht dingen altijd met zo min mogelijk beheer op te zetten. Dan hou ik tijd over voor andere leuke dingen.

Docker Swarm met Portainer heeft dat goed voor elkaar gekregen. Ik wil dus kijken of ik dat met k3s ook kan, en mogelijk beter doordat er steeds meer support komt voor k3s tov Docker Swarm

Het aantal cookbooks/recepten valt nog tegen voor k3s, maar wordt wel beter.

---
En met KubeVirt kun je binnen je cluster ook nog VM's draaien als dat nodig is. Je zou zelfs 1 master node baremetal kunnen installeren, en dan via KubeVirt een tweetal VM's met agents om je k3s cluster uit te breiden. Heb je geen Proxmox of wat dan ook meer nodig ook

[Voor 6% gewijzigd door Mars Warrior op 17-08-2020 11:55. Reden: KubeVirt]

[Falcon]

Onlangs tijdens een academy/Google Friday moment even mogen spelen met Azure Kubernetes Service en daarop draaiend een Jmeter Distributed Framework node(s) (Parent/Child) (voor load/performancetesten) en voor Monitoring (Grafana en Influxdb).

Hiervoor heb ik dankbaar gebruik gemaakt van deze Github repo: https://github.com/petegrimsdale/aks_testing_fwk




Dit allemaal draaiend op mijn gratis centjes vanuit mijn MPN licentie.

[Voor 8% gewijzigd door Falcon op 17-08-2020 13:22]

[TweakMDS]

Douweegbertje schreef op maandag 17 augustus 2020 @ 10:04:
[...]


Even los van dat ik je setup helemaal tof vind, ik val over je productie-proof en production-grade
Naar mijn inziens gaat dat veel verder en komt er meer bij kijken.

Helemaal terecht. Met production-proof bedoel ik vooral dat de technieken die ik gebruik, en hoe ik mijn applicaties deploy hetzelfde werken als op een productie cluster.
Ik probeer niet te impliceren dat mijn K3s cluster production grade is, daar komt inderdaad heel wat meer bij kijken

Ik zit nu trouwens live in KubeCon

[Voor 3% gewijzigd door TweakMDS op 17-08-2020 14:12]

[Mars Warrior]

SndBastard schreef op maandag 17 augustus 2020 @ 14:11:
[...]
Helemaal terecht. Met production-proof bedoel ik vooral dat de technieken die ik gebruik, en hoe ik mijn applicaties deploy hetzelfde werken als op een productie cluster.
Ik probeer niet te impliceren dat mijn K3s cluster production grade is, daar komt inderdaad heel wat meer bij kijken

Ik zit nu trouwens live in KubeCon

Gebruik je toevallig dan GitOps en dus ook Flux voor de deployment in combinatie met sealed secrets?

[TweakMDS]

Mars Warrior schreef op maandag 17 augustus 2020 @ 21:49:
[...]

Gebruik je toevallig dan GitOps en dus ook Flux voor de deployment in combinatie met sealed secrets?

Op het werk zitten we nu met GitHub Actions icm Azure AKS voor onze CI/CD en een hele berg helm charts. Voor onze productie deployments zijn we nu op zoek naar een goeie tool om wat beter meerdere on-prem/private cloud instanties te kunnen supporten, en de kandidaat die nu voor staat is Spinnaker.
Maar om eerlijk te zijn zwemmen we afentoe in mogelijke tools.
Na de komende 3 dagen KubeCon verwacht ik van mijn collega's minstens 5 nieuwe tools
(Flux parkeer ik wel even in de "ff doorlezen" map.)

Om alles wat meer in context te plaatsen, ik ben eigenlijk manager van development en ops, met een technische achtergrond (van ca. 18 jaar development en architectuur), maar ik doe nog altijd graag mee en blijf graag bij. Zit zelf op het werk wel wat minder diep in de details, maar mede daarom probeer ik wel up to date (of liever nog koploper) te blijven.

[Douweegbertje]

SndBastard schreef op maandag 17 augustus 2020 @ 23:57:
[...]


Op het werk zitten we nu met GitHub Actions icm Azure AKS voor onze CI/CD en een hele berg helm charts. Voor onze productie deployments zijn we nu op zoek naar een goeie tool om wat beter meerdere on-prem/private cloud instanties te kunnen supporten, en de kandidaat die nu voor staat is Spinnaker.
Maar om eerlijk te zijn zwemmen we afentoe in mogelijke tools.
Na de komende 3 dagen KubeCon verwacht ik van mijn collega's minstens 5 nieuwe tools
(Flux parkeer ik wel even in de "ff doorlezen" map.)

Om alles wat meer in context te plaatsen, ik ben eigenlijk manager van development en ops, met een technische achtergrond (van ca. 18 jaar development en architectuur), maar ik doe nog altijd graag mee en blijf graag bij. Zit zelf op het werk wel wat minder diep in de details, maar mede daarom probeer ik wel up to date (of liever nog koploper) te blijven.

Ik ben recent bezig met kijken naar ArgoCD. Misschien ook waard om te checken

[Mars Warrior]

Douweegbertje schreef op dinsdag 18 augustus 2020 @ 09:20:
[...]
Ik ben recent bezig met kijken naar ArgoCD. Misschien ook waard om te checken

Argo en Flux zijn tegenwoordig saampjes aan het ontwikkelen, heet dus nu Argo Flux

Zie hier hun eerste resultaat: https://github.com/argoproj/gitops-engine

Flux was altijd simpeler zonder GUI en 1 github repo, maar wel een update van images.
Argo heeft een GUI en kan meerdere github repo’s aan...

[Mars Warrior]

Het blijft een hoop ge-etter moet ik zeggen.

Dacht even wat losse tutorials te volgen om simpel een 1 node k3s cluster op te zetten, maar veel tutorials kloppen dus niet. Enkel foutmeldingen, en dan zoek je je rot om het te herstellen...

Zeker de combi met metallb en traefik is slecht te vinden op de helm manier.
Het Traefik dashboard krijkgik dus ook niet aan de praat helaas.

Het dashboard was ook ff lastig om rollen etc. aan te maken. Dat stond lekker nergens in de tutorial...



Dus @SndBastard , mocht je tijd hebben. Een tutorial is erg fijn

PS. Dit is een VM met 2GB RAM, 50GB disk en Ubuntu 20.04.1 LTS op een W10 bak onder Hyper-V

---
Ik zie nu dat een deel van de tutorials die ik her en der vond uit begin 2019 zijn. Dat verklaart dat ze dus deels niet meer werken. Dat heb ik jaren geleden ook met Docker / Docker Swarm gehad. Tuts van > 1 jaar kon je negeren

Ik had dus nu dat cli parameters gewoon foutmeldingen geven omdat die in de recente versie van bijv kubectrl niet meer geldig zijn

De gitops aanpak lijkt steeds fijner te zijn icm flux. Dan moet je wel weten wat je moet wijzigen of aanvullen in die mega yaml charts, maar je weet wel dat het klopt wat je invult uiteindelijk. En het is reproduceerbaar.

Waar ik ook last van had is dat het cluster "onbereikbaar is". Blijkt dat de KUBECONFIG omgevingsvariabele niet correct te zijn Moet ik elke keer bij inloggen

code:

export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

opgeven om eea te laten werken...

Een aantal services doen het, maar dat Traefik2 dashboard blijft onbereikbaar of onbekend:

[Voor 39% gewijzigd door Mars Warrior op 19-08-2020 09:43]

[Douweegbertje]

@Mars Warrior

Je kan op zich meerdere configs meegeven:

export KUBECONFIG=/etc/rancher/k3s/k3s.yaml:~/.kube/whatever:~/.kube/more

Eventueel in je bashrc of whatever floats your boat

Omdat ik aardig wat clusters gebruik vind ik het handig om "ktx" te gebruiken om te switchen: https://github.com/heptiolabs/ktx

idem als "kns"

[TweakMDS]

Mars Warrior schreef op dinsdag 18 augustus 2020 @ 23:06:

Dus @SndBastard , mocht je tijd hebben. Een tutorial is erg fijn

Mijn tutorials gaan nog even op zich laten wachten, omdat ik dat wel ga pairen met alles even vers doen (op een nieuwe machine).
Disclaimer: Even héél kort door de bocht.

Vwb K3s installatie: hetgeen wat veranderd is, is volgens mij de optie --no-deploy vs de optie --disable. Volgens dit issue is --no-deploy deprecated en zou je --disable moeten gebruiken, maar --no-deploy werkte tijdens mijn installatie nog wel.
Ik heb in mijn notepad dit staan om een master node uit te rollen - met in hoofdletters de opmerking van mezelf erbij "CURRENT WORKING":

Stap 1: K3s

code:

curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=latest INSTALL_K3S_EXEC="--no-deploy=servicelb" sh -

Ik zou overigens wel altijd voor een master en tenminste één worker node gaan; liefst twee, maar da's mijn eigen smaak.

Stap 2: MetalLB
Voor metallb heb ik redelijk de docs gevolgd, maar dit is in ieder geval mijn configmap.

code:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.178.235-192.168.178.240

Stap 3: Traefik configuration
De built-in traefik is niet helemaal praktisch te configureren. Beter wellicht om deze helemaal niet default uit te rollen en specifiek neer te zetten, maar je kan hem (beetje vies) configureren door er na installatie met kubectl een values file tegenaan te gooien.
Ik gebruik het dashboard niet, maar dat zou je hier aan toe kunnen voegen.
In mijn tutorial serie ga ik wel voor Traefik 2 denk ik.

code:

apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: traefik
  namespace: kube-system
spec:
  chart: https://%{KUBERNETES_API}%/static/charts/traefik-1.81.0.tgz
  valuesContent: |-
    rbac:
      enabled: true
    ssl:
      enabled: true
    metrics:
      prometheus:
        enabled: true
    kubernetes:
      ingressEndpoint:
        useDefaultPublishedService: true
    acme:
      enabled: true
      challengeType: tls-alpn-01
      email: <YOUR EMAIL ADDRESS>
      staging: false
      logging: true
    ssl:
      enabled: true
      enforced: false
      tlsMinVersion: VersionTLS12
      cipherSuites: [
        "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
        "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
        "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
        "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
      ]
    image: "rancher/library-traefik"
    tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: "node-role.kubernetes.io/master"
        operator: "Exists"
        effect: "NoSchedule"

Als je geen andere loadbalancer adressen gebruikt zal traefik nu .235 pakken, en daar kan je vervolgens poort 443 naartoe port-forwarden op je router.

Edit: makkelijke methode die ik pas na een paar maanden vond; om values files binnen te harken:

code:

helm show values stable/traefik > values.yml

Daarmee kan je wellicht wat meer sense maken van de syntax zoals die nodig is.

[Voor 6% gewijzigd door TweakMDS op 19-08-2020 10:39]

[Mars Warrior]

Aha!

k3s:

code:

export KUBE_EDITOR="nano"
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

export K3S_KUBECONFIG_MODE="644"
export INSTALL_K3S_EXEC=" --no-deploy servicelb --no-deploy traefik"
curl -sfL https://get.k3s.io | sh -s - --docker

Ik heb dus ook nog wat oude settings gebruikt die het doen. Ook gebruik ik docker omdat een aantal apps dat voorschrijven.

metallb:

code:

helm install metallb stable/metallb --namespace kube-system  \
--set configInline.address-pools[0].name=default   \
--set configInline.address-pools[0].protocol=layer2  \
--set configInline.address-pools[0].addresses[0]=192.168.2.150-192.168.2.175

Ik gebruik dus ook Traefik 2, oftewel traefik/traefik, en niet stable/traefik. Dat is v1 namelijk.

Maar de echte yaml files lijken me dus makkelijker en voorspelbaarder uiteindelijk, temeer daar ik deze in github kan zetten en op die manier zou kunnen deployen. Als alles - zoals flux - het doet natuurlijk...

@Douweegbertje, ik weet niet heel veel van Linux, dus .bashrc kende ik nog niet, maar daar heb ik nu de exports in gezet. Weer wat geleerd. Meestal copy/paste ik alle commando's vanuit de tut naar de terminal

Zo heb ik in het verleden ook een 20 node (80vCPU) Docker Swarm weten op te zetten en zelfs een compleet Hadoop cluster, al was dat qua onderhoud voor mij veels te hoog gegrepen, maar daarvoor heb je dan weer specialisten of mensen die dat willen worden

[Voor 19% gewijzigd door Mars Warrior op 19-08-2020 12:55]

[TweakMDS]

@Mars Warrior
Ik zit inderdaad nog/weer op Traefik 1. In geval van Traefik 2, vergeet uiteraard alles wat ik daarover heb gezegd, die zou het inderdaad wel OOTB moeten doen zonder workarounds, bij mij destijds in ieder geval wel.
De code die ik post is puur uit laziness omdat ik op die manier traefik 1 configureer na standaard install. Dat kan en moet eigenlijk ook netter, maar ben geen van van die configmaps met toml files.

Voor K3s heb ik overigens geen specifieke instelling voor docker als container runtime gedaan, maar draai gewoon containerd als default. Puur uit interesse, waar loop je tegenaan wat docker als container runtime nodig heeft? Ik heb wel gewoon een aantal containers in docker gemaakt die prima onder containerd draaien.

[Mars Warrior]

SndBastard schreef op woensdag 19 augustus 2020 @ 13:47:
@Mars Warrior
Ik zit inderdaad nog/weer op Traefik 1. In geval van Traefik 2, vergeet uiteraard alles wat ik daarover heb gezegd, die zou het inderdaad wel OOTB moeten doen zonder workarounds, bij mij destijds in ieder geval wel.
De code die ik post is puur uit laziness omdat ik op die manier traefik 1 configureer na standaard install. Dat kan en moet eigenlijk ook netter, maar ben geen van van die configmaps met toml files.

Voor K3s heb ik overigens geen specifieke instelling voor docker als container runtime gedaan, maar draai gewoon containerd als default. Puur uit interesse, waar loop je tegenaan wat docker als container runtime nodig heeft? Ik heb wel gewoon een aantal containers in docker gemaakt die prima onder containerd draaien.

Piraeus oa eist de docker container runtime (https://github.com/piraeusdatastore/piraeus). Nu gebruikt Docker volgens min ook containerd, dus kan best zijn dat dat gewoon werkt, maar ik heb nu dus extra vooraf docker geïnstalleerd vanuit de docker repo.

Het blijft toch wel lastig zo. Er is maar zeer weinig uitleg in de zin van ik wil xyz doen, welke velden in die enorme yaml files zijn dan van belang en hoe stel ik die in. En daarbij wat is de onderlinge relatie tussen al die yaml files.

De vaak technische documentatie vertelt regelmatig geen samenhang, iets waar ik altijd eerst naar zoek.

Ben niet de enig die daarover ‘klaagt’: https://community.contain...elm-404-on-dashboard/3753. Wie weet is dat de oplossing voor dat niet werkende dashboard...

[Voor 5% gewijzigd door Mars Warrior op 19-08-2020 18:54]

[TweakMDS]

Mars Warrior schreef op woensdag 19 augustus 2020 @ 18:29:
[...]
Piraeus oa eist de docker container runtime (https://github.com/piraeusdatastore/piraeus). Nu gebruikt Docker volgens min ook containerd, dus kan best zijn dat dat gewoon werkt, maar ik heb nu dus extra vooraf docker geïnstalleerd vanuit de docker repo.

Boeiend, ik zie het daar inderdaad bij staan, en niet alleen docker als container runtime, maar ook nog eens heel specifieke requirements over distributies, hoewel ik niet helemaal kan plaatsen wat dat inhoudt.
Bij zoiets lezen bekruipt me toch een beetje het gevoel dat het niet helemaal kubernetes-proof is, maar daar zou ik me verder in moeten verdiepen.

Het blijft toch wel lastig zo. Er is maar zeer weinig uitleg in de zin van ik wil xyz doen, welke velden in die enorme yaml files zijn dan van belang en hoe stel ik die in. En daarbij wat is de onderlinge relatie tussen al die yaml files.

De vaak technische documentatie vertelt regelmatig geen samenhang, iets waar ik altijd eerst naar zoek.

Ben niet de enig die daarover ‘klaagt’: https://community.contain...elm-404-on-dashboard/3753. Wie weet is dat de oplossing voor dat niet werkende dashboard...

Ben ik met je eens; het installeren van bestaande helm charts is vaak een relatief ellendig iets.
Een greep uit de random shit die ik ben tegengekomen: configurables die niet doen wat ze zouden moeten doen, auto-ingress opties (alleen true/false hoeven zetten), die vervolgens alleen met een specifieke ingress controller werken, node-port opties op services die er gewoon hard ingebakken zijn, PVC's die onnodig worden aangemaakt, of met foutieve storage classes, helm charts die enorm ver achter lopen op de laatste stable docker images, of die juist :latest gebruiken, wat op lange termijn nog meer problemen kan geven.

Een goed voorbeeld van wat als helm chart niet helemaal lekker werkt vind ik die van node red. Die mist gewoon configuratie opties die echt nodig zijn, zoals authenticatie aanzetten, of überhaupt een oplossing om de configuratie-file als configmap neer te zetten. Op dit moment is de enige praktische manier om op de pod in te loggen en de file met nano te editen. Da's niet ideaal.

Uiteindelijk wordt dat spul vaak ook gewoon door mensen zoals jij of ik maintained, en is het meer een tool om snel te kunnen starten. Ik zou er eigenlijk wel wat actiever in kunnen contributen als ik iets tegen kom, maar da's vaak ook weer een heel ding.

Zoals ik het zie - als je bedrijfsmatig met Kubernetes aan de slag gaat is de overhead om je eigen helm charts te maken niet zo groot. Zo doen wij het nu in ieder geval ook.

[Mars Warrior]

Ik herken de puinhoop steeds meer

De documentatie van Rancher/k3s zelf mis je zelfs de installatie opties die je hebt. Op de japanse site vind ik die weer wel, maar lijken ook weer achter te lopen.

Kijk in de de dingen die ik nu gebruik dan zie ik nog heel veel v1beta api verwijzingen, terwijl sinds v1.9 - we zitten nu bij v1.18 - de meeste object api's op v1 zitten

En dan heb ik het nog niet over de naamgevingen die veel mensen gebruiken. Ik merk dat dit erg verwarrend is voor mij. Immers "traefik-ingress-controller". Tja, wat is dit nu? Alles heet in dit geval traefik-ingress-controller. En ja dat mag, maar vind ik wel erg verwarrend.

code:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: traefik-ingress-controller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: traefik-ingress-controller
subjects:
- kind: ServiceAccount
  name: traefik-ingress-controller
  namespace: kube-system

Mijn voorkeur is dan de volgende:

code:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: traefik-crb
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: traefik-cr
subjects:
- kind: ServiceAccount
  name: traefik-sa
  namespace: kube-system

Of andersom, dus eerst het object, dan dus crb-treafik etc.

Hetzelfde voor yml/yaml files. Sommigen gebruiken daar fijne naamgevingen voor, dus bijv. traefik.serviceaccount.yaml, of traefik.sa.yaml met bijbehorende cluster role binding treafik.crb.yaml. Oftewel: de kubernetes objecten zijn herkenbaar en dus ook makkelijk te vinden als je wat zoekt omdat je ook in de yaml file direct ziet dat je een service account gebruikt. Scheelt een hoop typefouten en deployfouten

Ook is het zoeken een stuk fijner in een tekstverwerker. En ik kan dus ook veel beter zien wat nu aan elkaar hangt op basis van namen.

Maar deze wens kan ook aan mij liggen. Ik raak wat snel in de war als alles hetzelfde heet
Doen we in de echte wereld ook niet. Als we alles "Fikkie" gaan noemen wordt het een zooitje, al kan het ook voordelen hebben als je al je vrouwen "Fikkie" noemt

@SndBastard Die ervaringen zijn voor mij reden te meer om iets als GitOps toe te passen: dan gebruik je je eigen yaml files om je cluster op te bouwen. Moet je dan ook zelf bijhouden natuurlijk, maar je weet zeker dat ze werken. Dus een bestaande hergebruiken / wijzigen, en zelf opslaan. Dan is het altijd voorspelbaar wat je doet/krijgt... Kun je ook lekker eigenwijs je eigen naamgeving gebruiken

[Voor 8% gewijzigd door Mars Warrior op 20-08-2020 12:10]

[Mars Warrior]

Toch nog wat gevonden!

Als je maar op meer steekwoorden zoekt, en niet op de 1ste pagina van Google zoekresultaten afhaakt, maar een paar pagina's doorklikt, dan vind je toch nog wat!

Traefik2:
Installatie inclusief het Traefik dashboard via ingresss. Op zijn github pagina staan de echte voorbeelden hoe hij het heeft gedaan
- https://ralph.blog.imixs....2-and-kubernetes-ingress/
- https://imixs.github.io/imixs-cloud/doc/INGRESS.html

Het verschil tussen Traefik IngressRoute en de standaard K8s Ingress definities staat ook uitgelegd

k8s Dashboard:
Op deze site van k8s AWS tooling staat zowaar uitgelegd hoe je het k8s dashboard via ingress - in dit geval nginx, ga ervan uit dat het met Traefik analoog is - kunt configureren. Met tls/https natuurlijk
- https://kubernetes-incuba...kubernetes-dashboard.html

Nog helemaal niks uitgeprobeerd hoor, moet ff door met andere belangrijke dingen namelijk, maar het ziet er wel naar uit dat ik nu voorbeelden heb gevonden van hoe ik het zou willen

Als dan het toevoegen van Authelia ook nog lukt, dan heb ik mi een goed beveiligde https/mfa toegang (overal) van deze dashboards, en natuurlijk een mooi voorbeeld voor andere apps zoals BookStack en Bitwarden!

[TweakMDS]

@Mars Warrior
Mooi om vooruitgang te zien! Het configureren van ingress heb je na een paar pogingen makkelijk vanzelf onder de knie. Zoals ik het nu doe gebruik ik daar mijn eigen templates voor, eigenlijk pas ik dan maar een paar dingen aan: Naam + namespace van de ingress, de url aan de buitenkant, en de service naam + poort in het cluster.
Voor mij geld een beetje - hoe meer ik met K8s doe, hoe makkelijker het wordt, en hoe minder ik de standaard "off the shelf" scripts gebruik.

[Douweegbertje]

SndBastard schreef op donderdag 20 augustus 2020 @ 22:09:
@Mars Warrior
Mooi om vooruitgang te zien! Het configureren van ingress heb je na een paar pogingen makkelijk vanzelf onder de knie. Zoals ik het nu doe gebruik ik daar mijn eigen templates voor, eigenlijk pas ik dan maar een paar dingen aan: Naam + namespace van de ingress, de url aan de buitenkant, en de service naam + poort in het cluster.
Voor mij geld een beetje - hoe meer ik met K8s doe, hoe makkelijker het wordt, en hoe minder ik de standaard "off the shelf" scripts gebruik.

Uhu. Geef het tijd.
Een beetje de bekende tijdslijn is dat je begint en niet snapt wat het allemaal is. Daarna valt het kwartje en wordt het beter. En vervolgens ga je er nog dieper in en kom je in de fase waarin je helemaal niet meer weet waar je aan begonnen bent

Dus geniet er nog even van

[g1n0]

Douweegbertje schreef op donderdag 20 augustus 2020 @ 23:06:
[...]
Uhu. Geef het tijd.
Een beetje de bekende tijdslijn is dat je begint en niet snapt wat het allemaal is. Daarna valt het kwartje en wordt het beter. En vervolgens ga je er nog dieper in en kom je in de fase waarin je helemaal niet meer weet waar je aan begonnen bent

Dit is zo herkenbaar. Zie het maar een beetje als een vicieuze cirkel Je bent nooit ‘klaar’

[Mars Warrior]

En ondertussen op een andere planeet, ziet er naar uit dat een deel van mijn problemen komt door het gebruik van nftables als backend in plaats van iptables. Nftables is standaard voor de laatste Ubuntu en Debian versies.

Daardoor doet K8s proxy het niet meer en kun je ook niet tussen verschillende nodes/pods fatsoenlijk communiceren. Gelukkig kun je weer terugschakelen naar het al oude iptables legacy als backend...

Dit issue van eind 2018 is gesloten, maar er hangen talrijke andere issues aan vast die nog open staan als je ff naar het einde doorscrolled: https://github.com/kubernetes/kubernetes/issues/71305

[Mars Warrior]

Hebben jullie wel eens naar je CPU load gekeken?

Ik heb een constante hoge load van ca 40% veroorzaakt door de k3s-server.
Dit zonder verder ook maar iets van een container te hebben toegevoegd, dus een kale installatie.

Er zijn meerdere topics voor deze hoge CPU load, maar opgelost is het nog steeds niet.

Vraag me dus af wat jullie zien, welk OS je draait en hoeveel cores dat systeem heeft.

[Douweegbertje]

Mars Warrior schreef op dinsdag 25 augustus 2020 @ 17:52:
Hebben jullie wel eens naar je CPU load gekeken?

Ik heb een constante hoge load van ca 40% veroorzaakt door de k3s-server.
Dit zonder verder ook maar iets van een container te hebben toegevoegd, dus een kale installatie.

Er zijn meerdere topics voor deze hoge CPU load, maar opgelost is het nog steeds niet.

Vraag me dus af wat jullie zien, welk OS je draait en hoeveel cores dat systeem heeft.

Ik draai vooral op managed systemen en alles wat ik zelf draaide was k8s, niet k3s.

Maar anyhow. Je hebt het over CPU load en vervolgens over een % load.
(CPU, want eigenlijk gewoon system) load is anders dan CPU usage % bijvoorbeeld. Dan is het ook de vraag hoe je dit bekijkt. Soms is de % van een single CPU, niet van heel je systeem.

En de vraag is in hoeverre een load van 40% (van wat? ) "hoog" is. Beetje afhankelijk van je gehele systeem, cores, type cpu's natuurlijk.

[Mars Warrior]

Douweegbertje schreef op dinsdag 25 augustus 2020 @ 22:17:
[...]Ik draai vooral op managed systemen en alles wat ik zelf draaide was k8s, niet k3s.

En de vraag is in hoeverre een load van 40% (van wat? ) "hoog" is. Beetje afhankelijk van je gehele systeem, cores, type cpu's natuurlijk.

Het gaat om cpu percentage. Die piekt tot 130%. Ik heb 4vCPU toegewezen. Moet ik dan dit % eigenlijk door 4 delen? Linux werkt dan anders dan Windows. Oftewel Windows is max altijd 100%, en Linux in dit geval 400%?

Ik zag nl als ik 1 vCPU toewijs ik rond de 10-15% uitkom. Voor een systeem dat ‘niks’ doet vind ik dat nog veel.
En ik ben niet de enige. Daarnaast klagen mensen over de systeem load die boven de 10 uitkomt, waardoor de computer nog nauwelijks reageert...

Alles wijst naar het k3s-server proces die dus behalve behoorlijk wat CPU tijd vreet, de rest van het systeem ook met de nodige I/O belast. Vooral mensen met een RPI klagen hierover omdat het SD kaartje gemold wordt hierdoor.

K3s is bedoeld voor kleine devices met weinig resources. Met zo’n hoog CPU en I/O gebruik is dat niet handig.

Mijn docker swarm systemen hebben met tig containers een lagere load dan een kaal k3s systeem zonder load balancer en ingress app en dus ook nog zonder eigen containers.

Verder ook zonde van het stroomverbruik.

Voorlopig geeft ook geen enkele dev uitleg waarom dat proces zo druk is. Vind ik vreemd als dat niet lukt
Alle andere processen zitten rond de 1% CPU gebruik of lager.

[Douweegbertje]

Mars Warrior schreef op dinsdag 25 augustus 2020 @ 22:43:
[...]

Het gaat om cpu percentage. Die piekt tot 130%. Ik heb 4vCPU toegewezen. Moet ik dan dit % eigenlijk door 4 delen? Linux werkt dan anders dan Windows. Oftewel Windows is max altijd 100%, en Linux in dit geval 400%?

Nja ten eerste: no shit dat linux anders is dan windows
En ten tweede, Linux != "het programmaatje dat jij gebruikt om je cpu te meten" - Dat is gewoon een "feature" van `top`

130% zal dan inderdaad ~32% van je gehele systeem zijn met 4 cores. Maar zonder duidelijke insights is het nog steeds maar wat lukraak roepen van mij

Ik zag nl als ik 1 vCPU toewijs ik rond de 10-15% uitkom. Voor een systeem dat ‘niks’ doet vind ik dat nog veel.
En ik ben niet de enige. Daarnaast klagen mensen over de systeem load die boven de 10 uitkomt, waardoor de computer nog nauwelijks reageert...

Alles wijst naar het k3s-server proces die dus behalve behoorlijk wat CPU tijd vreet, de rest van het systeem ook met de nodige I/O belast. Vooral mensen met een RPI klagen hierover omdat het SD kaartje gemold wordt hierdoor.

K3s is bedoeld voor kleine devices met weinig resources. Met zo’n hoog CPU en I/O gebruik is dat niet handig.

Mijn docker swarm systemen hebben met tig containers een lagere load dan een kaal k3s systeem zonder load balancer en ingress app en dus ook nog zonder eigen containers.

Verder ook zonde van het stroomverbruik.

Mja ik snap je punt wel maar om even te nuanceren:

- Mensen zijn sowieso geneigd om hun problemen te posten in plaats van dat het wel werkt.
- Als ik naar de inhoud van het github issue kijk zie ik maar weinig kwaliteit. Ik kan namelijk ook niets met de input vanuit zo'n issue. Je hebt dan toch echt het volgende benodigd:

- Goede dumps van de processen
- Duidelijke metrics van het gehele systeem
- Duidelijk omschrijving waar het op draait. OS, versions, software (+versions), type CPU, type Memory, type HD

Want de ene CPU is de andere niet. Als je namelijk 30% CPU van een Pi3 verbruikt dan heb je het over een 1200MHz ARM processor. Zeg maar 100% load op zo'n ding is misschien 5% van mijn cpu in de laptop waar ik nu op typ

Voorlopig geeft ook geen enkele dev uitleg waarom dat proces zo druk is. Vind ik vreemd als dat niet lukt
Alle andere processen zitten rond de 1% CPU gebruik of lager.

Welkom bij Open Source
Als je het echt vervelend vindt dan kan je het zelf proberen te fixen. Dat is natuurlijk wel een beetje de insteek van zo'n product. In fairness, het issue waar jij in hebt gereageerd is closed. Closed omdat de starter van het issue het eigenlijk wel logisch/goed vond.

---

Een serieuze note.
Als je het echt vervelend vindt en je wilt het gefixed hebben, zou je dan een nieuw issue kunnen aanmaken? Eentje waarin 100% overduidelijk is dat er iets niet klopt aan k3s. Dus duidelijk stats en een duidelijk indicatie dat er geen onderliggende issues zijn (met je host OS of whatever) en duidelijk zichtbaar inclusief redenatie waarom k3s te veel CPU gebruikt?
Dan ga ik er zelf eens naar kijken en/of ik bespreek het met Rancher

[TweakMDS]

Aan de buitenkant van mijn cluster (dus in Proxmox) draait het nu als volgt:

Dus inderdaad wel ~40 CPU op de master.

Aan de binnenkant van mijn cluster ziet dat er wat anders uit:


Dit is op een i5-4250u, dus 2 cores, 4 threads, aardappel-niveau CPU. Het systeem is niet echt heel erg in rust, maar ook niet heel hard aan het werk.
Als ik wat dieper in grafana duik lijkt met name de local-path-provisioner het meeste te doen. Ik zal er in de komende week eens verder naar graven.

[Voor 6% gewijzigd door TweakMDS op 26-08-2020 10:57]

[Mars Warrior]

Ik ben geen programmeur, dus zelf ff wat fixen wordt lastig. Verder ben ik wel gewend om met open source te werken, maar ook veel met veiligheidssystemen, en daar is het vanzelfsprekend dat een ontwikkelaar het gedrag van zijn software kent onder verschillende omstandigheden!

In mijn teams kan een ontwikkelaar onmogelijk een issue sluiten zonder enige onderbouwing

Als ik ff verder neus dan zie ik dat:

• Minikube ook de nodige shit heeft qua cpu. Al vanaf 2018, en pas recent opgelost
• Microk8s heeft een hele lage load, 0.5-1% per k8s proces (apiserver, controller), dus 3-5% idling. Die hebben het kennelijk wel goed onder controle
• k3s server proces (wat een verzameling is van alle k8s processen) zit dus behoorlijk hoog. De local-path-provisioner komt bij mij ook geregeld hoog in de lijst als er wat draait. Geen idee waarom.

De ca 40% cpu load wordt dus ook gezien door @SndBastard . Dat is fijn. Ik heb zelf dus al twee verschillende OSsen getest met 4.x en 5.x kernel. Maakt niet uit blijkt uit mijn testen.

Met atop zie ik een behoorlijk hoge "write data transfer issued physically on disk". Maar wat dat ding continue naar disk staat te schrijven staat er niet bij. Is wel iets wat dus ook door RPI gebruikers wordt gemeld, en dat dat de SD kaart natuurlijk om zeep helpt.

De disk staat continue op 100% belasting zie ik ook:


Als ik zie wat MiniKube heeft moeten doen, dan heeft het veel met timing en periodieke controles te maken die worden uitgevoerd. Vreemd genoeg hebben de gecontroleerde processen hier geen last van met een CPU load van < 1%.

Mocht ik zin hebben @Douweegbertje , dan maak ik nog wel een nieuw issue aan. Wie weet wordt er dan wel wat mee gedaan als jij je er ook nog tegenaan bemoeit

Voor nu wacht ik ff op 1.19 van k3s die begin september zou moeten uitkomen. Verder is 1.20 ook wel erg fijn in december omdat ze daar Traefik 2.0 standaard inbouwen. Daarnaast ook ondersteuning voor hot standby.

In de backlog staat ook nog een hele tijd "Improve low-power support", dus het heeft wel degelijk de aandacht zou ik mogen zeggen, al blijkt dat dus nog niet uit het oplossen van aangemelde issues.
Dat een issue soms weinig gegevens bevat dat mag geen probleem zijn om profiling uit te voeren door één van de ontwikkelaars. Die hebben de tools namelijk. En als zij die load niet zien, kunnen zij toch ook simpel hun systeem ff speccen en een screenshot van top laten zien

Edit1:
Met lsof zie ik dat k3s-server schrijft naar oa /var/lib/rancher/k3s/agent/containerd/containerd.log en natuurlijk de sqlite database /var/lib/rancher/k3s/server/db/state.db-wal. Die laatste wordt met 1.19 vervangen door etcd. Dus als dat het probleem is, dan zou dat over moeten zijn...

Dan zal dit issue ook niet meer van toepassing zijn. Mijn database is niet groot overigens.

Helaas kan ik dan weer niet zien met lsof hoeveel er geschreven wordt naar die state database. Is er niet gewoon een processexplorer equivalent onder Linux

Ben er weer ff klaar mee

[Voor 22% gewijzigd door Mars Warrior op 26-08-2020 14:38. Reden: Plaatje erbij gedaan...]

[Mars Warrior]

Zo, maar weer even een post hier.

De releases van k3s hebben nogal wat vertraging opgelopen door blocking issues en patchwerk. Dus 1.19 is nog niet uit, en gaat ook niet meer uitkomen, dat wordt 1.19.1 of zelfs 1.19.2.

Het blijft dus wachten.

Nu was ik wel aan het kijken of ik ipv een master/worker opzet een 3-node master zou kunnen doen. Dat geeft een stuk meer zekerheid dat bijv. mijn domotica blijft doorlopen als onverhoopt de master uit zou vallen.

Gelukkig had een ander dat ook al getest, en na een reboot blijkt het cluster niet meer op te komen

Dus dat lijkt een volgend blocking issue.

En verder zijn er natuurlijk nog issues die het hebben over de hoge CPU en I/O load. Mensen die een externe database gebruiken (ipv etcd) in een multi-master setup hebben het over databases die met gigabytes groeien en uiteindelijk compleet vastlopen

Ze hebben dus nog wat dingen op te lossen om een stabiele versie op te leveren. Kan zijn dat de embedded etcd oplossing experimenteel blijft, dus voor eigen risico, zodat ze toch die versie kunnen uitrollen.

[TweakMDS]

Het is hier alweer even stil... Mijn cluster gebaseerd op K3s draaide veel te stabiel, dus tijd voor een teardown en om iets anders te proberen.
Vanmorgen zag ik in mijn newsfeed een aankondiging van HA MicroK8s voorbij komen (https://www.zdnet.com/art...ability-micro-kubernetes/)

Omdat ik Alpine + K3s fanboy was heb ik deze altijd links laten liggen, maar toch even snel in gedoken.
Op basis van een Ubuntu Server 20.4 LTS image deed hij het eigenlijk meteen, maar heb nog niet de HA optie geprobeerd.
Wat me wel op viel is dat de combinatie Ubuntu + MicroK8s meteen 93% memory van mijn bescheiden 4GB VM gebruikte. Bij Alpine met K3s was dat een héél stuk minder.
Waar ik vooral benieuwd naar ben is of de HA oplossing hier iets minder CPU gebruikt.

Doelen voor de komende avond / dagen dus:

• Ubuntu minder RAM laten gebruiken, volgens mij komt er vrij veel mee geïnstalleerd wat ik niet nodig heb.
• Hier een drietal van neerzetten op mijn VM server.
• MicroK8s cluster optuigen en me daarin een beetje bekend maken.

Verder kreeg ik de ingebouwde prometheus operator (https://microk8s.io/docs/addons#heading--list) niet werkend in combinatie met Lens (https://k8slens.dev/) dus ook dat is nog even puzzelen.

Heeft iemand van jullie hier al iets mee gedaan?

[Mars Warrior]

SndBastard schreef op donderdag 15 oktober 2020 @ 14:10:
Heeft iemand van jullie hier al iets mee gedaan?

Nope. Ligt even stil. Performance onder hyper-v is niet bepaald erg hoog met die grote I/O & CPU load...

Ik zag wel meldingen van mensen die dezelfde versie als ik draaien, maar dan de master op bare metal onder Ubuntu, en die hebben eigenlijk geen performance problemen. Draait erg 'licht' op de CPU.

Maar dat heb ik nog niet geprobeerd. Ik wil eigenlijk ook multi-master zodat uitval weinig tot geen pijn doet in bepaalde containers die lekker doordraaien. Heb dat nu 'opgevangen' door elke VM/bare metal doos te draaien onder zijn eigen docker swarm. Eigenlijk dus allemaal aparte single node k3s nodes als ik het zou vertalen naar kubernetes.

Ik zie nu dat HA Mikro8ks gebruik maakt van DQlite, iets wat ze bij k3s dus hebben laten vallen na de overstap op embedded etcd.

Ben benieuwd naar je resultaten.

[TweakMDS]

Qua geheugengebruik lijkt dat niet zo heel erg aan Ubuntu te liggen, maar gebruikt MicroK8s gewoon substantieel meer. Ik heb even een verse install gedaan. Na install en reboot + even laten lopen gebruikt Ubuntu 20.04 LTS "Server" zo'n 600MB. Da's vrij veel, maar wel te overzien. Na installatie van een "kale" MicroK8s (één node) loopt dat op tot ca. 3.5GB. Da's zonder ingress, metallb, coredns, prometheus of wat dan ook.
Daarmee weet ik niet of ik comfortabel 3 nodes op mijn hypervisor kan draaien, maar het is een mooie test om te zien of het daarmee echt bruikbaar is in mijn use case, of dat ik toch een server met meer memory erbij ga willen.



Kleine update; het aanmaken van een HA cluster met microk8s is erg voor de hand liggend, en werkt OOtB (op sample-rate van 1 natuurlijk).
Ik heb 3 ubuntu vm's met elk 2 cores, 4GB ram en een volume van 32GB gemaakt (te weinig denk ik in retrospect).

Ook het enablen van de add-ons nadat je een HA-cluster hebt gemaakt werkt soepel zoals het zou moeten werken. Bijvoorbeeld het aanzetten van CoreDNS na opzet van het hele cluster:


Geheugengebruik is voor mijn gevoel wat aan de hoge kant, maar de specs geven ook duidelijk 4GB minimum aan. Dat lijkt ook wel echt het minimum te zijn.
Verder krijg ik nog een aantal "invalid capacity 0 on image filesystem" maar die lost zichzelf vaak op, dus ik laat het even idle draaien.

[Voor 41% gewijzigd door TweakMDS op 15-10-2020 18:09]

[TweakMDS]

Nog een kleine update op het vorige: het MicroK8s cluster was niet stabiel.
Het goeie nieuws is dat de failover / leader election erg goed werkt, maar bleef dit elke paar minuten ook doen en gaf daarbij periodiek wel enkele fouten.
Ik heb het idee dat dat toch komt door te weinig geheugen / storage, dus ga als vervolg nog eens proberen om hem substantieel meer geheugen te geven, maar daarvoor heb ik eerst een nieuwe hypervisor nodig, dus dat mag even op de lange baan.

[Nindustries]

Misschien interessant voor sommigen, maar in mijn kennismaking met k8s & gitops heb ik volgende repositories open sourced die beschrijven hoe je:

- lokaal kan ontwikkelen in k8s en automatisch laten recompilen
- builden, testen, helm chart packagen en publishen op GitHub repo
- jouw app deployen a.d.h.v. helm met enkel GitHub

Go APIs: https://github.com/ironpeakservices/iron-chart-go
Hugo static websites: https://github.com/ironpeakservices/iron-chart-hugo

Alle PRs welkom.

[Mars Warrior]

Heeft hier al iemand k0s geprobeerd? Ik blijf ruzie houden met k3s namelijk, dus overweeg om k0s eens te proberen...

Verder heeft OpenEBS een nieuwe driver die goed performed: https://medium.com/volter...2020-updated-1c0b69f0dcf4

Alleen nog alpha. Dat is jammer.

[Broodje_Aap]

Zijn er mensen hier die bekend zijn met Cilium?

Ik heb 2 interfaces voor mijn host machines, 1 voor management, de ander voor netwerk performance testing. Nu merk ik dat Cilium al het verkeer alleen over het management netwerk stuurt en het performance netwerk niet bereikbaar is. Nu weet ik zeker dat het aan Cilium ligt, want ik heb een 2e cluster met exact dezelfde instellingen, op dezelfde VMWare machine, alleen draai ik daarop Calico in plaats van Cilium. Ook werkt pingen vanaf het host OS naar het performance netwerk ook zonder problemen.

Nu denk ik dat het aan de masquering instellingen van Cilium ligt. Ik zie dat de masquering van Cilium alleen op ens160 staat (management netwerk) terwijl ens192 het performance netwerk is.

Weet iemand toevallig hoe ik ens192 kan toevoegen aan de masquering? Ik ben wel https://docs.cilium.io/en.../masquerading/#masq-modes tegengekomen, maar ik heb werkelijk geen idee hoe ik dit kan implementeren in mijn

code:

cilium-config.yaml

.

Ik heb geprobeerd

code:

devices: ens192

toe te voegen aan de config yaml, maar hierdoor raken de Cilium pods in een CrashLookBackOff...

Weet iemand hier wat ik fout doe?

Alvast bedankt!

[Voor 3% gewijzigd door Broodje_Aap op 15-04-2021 15:12. Reden: tikfoutjes en missende woorden]

[_eXistenZ_]

Wij (Enrise) draaien er inmiddels 4 jaar mee in productie, mooi spul

Voornamelijk omdat je als team nu echt zelf devops kan doen en niet meer vast zit aan ouderwetse hostingpartijen die je vaak niet snappen of enorm traag opleveren.

[Voor 54% gewijzigd door _eXistenZ_ op 15-04-2021 16:40]

[TweakMDS]

Even tijd voor een kleine homelab update van mijn kant.

Ik heb nu twee hypervisors met Proxmox:

• Intel NUC met i5-4250u, 16GB RAM en een 256GB SSD.
• Lenovo M720Q met i5-9400T, 32GB RAM en twee 512GB SSD's.

Sinds het toevoegen van de Lenovo zijn eigenlijk alle storage en memory beperkingen die ik had wel een beetje opgelost. Ik kan nu vrij soepel twee clusters met een stapel nodes draaien.
Mijn "oude" K3s cluster draait nog op 3 alpine VM's (2-core, 4 GB), en werkt eigenlijk zonder problemen. Hij draait een aantal zaken die ik dagelijks gebruik, enkele kleine prototypes die ook wel eens door collega's gebruikt worden, en verder niet heel veel spannends.

Ik heb het concept van K3s in HA draaien een beetje los gelaten. In principe werkt het prima, maar het heeft bijzonder weinig toegevoegde waarde voor een homelab situatie, en de skills die ik ermee op heb gedaan vertalen zich ook maar mager naar productie situaties.
Ik heb nog even met de install scripts van "kaymeg" (https://github.com/cjrpriest/kaymeg) gespeeld. Met wat kleine modificaties aan de scripts werkt dat prima. Ik zou het niet direct aanbevelen, maar het is een leuke oefening voor mensen die graag wat script automation zonder ansible / terraform willen leren. Leuke oefening om eens doorheen te lezen.

Verder heb ik ook eindelijk een fatsoenlijk storage ingebouwd met gebruik van Longhorn. De applicaties die we zakelijk ontwikkelen hebben op een aantal pods shared storage (ReadWriteMany) nodig, en dat was met de K3s ingebakken Local-Path niet mogelijk.

De laatste versie van Longhorn (1.1.0) lost dit vrij elegant op, en het gaat nu helemaal vanzelf; binnen één en dezelfde storage class.

Gelukkig blijven er altijd wel wat hobby uitdagingen over. Nu ik meerdere clusters draai heb ik ook wel de behoefte om een interne ingress te doen, dus voor web-apps die niet direct aan mijn domeinnaam moeten hangen.
Ik zit al een tijdje te overwegen om daarvoor van Traefik2 naar Istio over te stappen, maar ben er nog niet helemaal uit.

Mars Warrior schreef op dinsdag 16 februari 2021 @ 18:29:
Heeft hier al iemand k0s geprobeerd? Ik blijf ruzie houden met k3s namelijk, dus overweeg om k0s eens te proberen...

Verder heeft OpenEBS een nieuwe driver die goed performed: https://medium.com/volter...2020-updated-1c0b69f0dcf4

Alleen nog alpha. Dat is jammer.

Nog niet, maar de timing is wel goed om dit ook eens te proberen. Ik heb wel nog een keer K3s en MicroK8s naast elkaar gehouden, en toch mijn voorkeur voor K3s nog bevestigd.

[Voor 12% gewijzigd door TweakMDS op 18-04-2021 18:45]

[cODAR]

Mars Warrior schreef op dinsdag 16 februari 2021 @ 18:29:
Heeft hier al iemand k0s geprobeerd? Ik blijf ruzie houden met k3s namelijk, dus overweeg om k0s eens te proberen...

Verder heeft OpenEBS een nieuwe driver die goed performed: https://medium.com/volter...2020-updated-1c0b69f0dcf4

Alleen nog alpha. Dat is jammer.

Ik vind k0s erg prettig, het is production ready sinds versie 1.21. Ik ben aan het onderzoeken of ik moet overstappen van Kubic naar k0s, voornamelijk omdat het zo enorm eenvoudig is.

k3s en k0s verschillen niet veel, k3s is wat meer opionated met local-path-provisioner en Traefik. Een mooie feature is dat je k0s eenvoudig kunt deployen met k0sctl (lach niet om die naam )

[TweakMDS]

cODAR schreef op vrijdag 30 april 2021 @ 22:52:
[...]


Ik vind k0s erg prettig, het is production ready sinds versie 1.21. Ik ben aan het onderzoeken of ik moet overstappen van Kubic naar k0s, voornamelijk omdat het zo enorm eenvoudig is.

k3s en k0s verschillen niet veel, k3s is wat meer opionated met local-path-provisioner en Traefik. Een mooie feature is dat je k0s eenvoudig kunt deployen met k0sctl (lach niet om die naam )

Ik heb wat met K0s gespeeld, maar vond toch een paar dingen flink tegenvallen. Ik kreeg k0sctl niet aan de gang in Alpine (musl in plaats van glibc), kreeg build errors op (een aantal) dependencies bij zelf builden, en vond het ook eigenlijk niet heel prettig om dat soort custom binaries nodig te hebben.
Een single node in Ubuntu server werkte verder prima, maar vergeleken met Alpine vind ik Ubuntu of zelfs Debian toch nog een hoop overhead hebben.

Het is wel allemaal nog erg vers, dus misschien binnenkort een verse poging geven op Debian en kijken hoe het dan bevalt.
De grootste voordelen van k3s die je noemt gebruik ik eigenlijk niet; ik installeer altijd zonder Traefik en ServiceLB, en installeer eigenlijk standaard Traefik 2, Longhorn en MetalLB.

Ik heb vorige week de VM's waar ik meestal op bouw wat meer gestandaardiseerd op basis van cloud-init, dus dat maakt het testen van alternatieve K8s distro's wel een heel stuk makkelijker.

Edit
Ik heb gisteren nog een 3 worker k0s cluster geïnstalleerd op basis van Ubuntu (met cloud init images in proxmox). Dat werkt toch eigenlijk wel heel erg soepel. Ik heb k0sctl nu vanaf de master gedraaid, wat eigenlijk nog niet helemaal netjes is, maar werkt prima. Enige minor issue om rekening mee te houden is dat hij dan naar zichzelf toe ssh'd, dus die key moet je ook toevoegen. Gelukkig is dat automagically geregeld met cloud init door gewoon een key toe te voegen.
Erg soepele setup, en ook een node toevoegen is gewoonweg een kwestie van de config file aanpassen en k0sctl apply draaien.
Hele cluster draaide in ongeveer 20 minuten; van machine provisioning tot en met cluster koppelen in rancher, en dat was inclusief uitzoeken hoe de config files van k0sctl werken.
Vervolgens heb ik er ook nog OpenEBS in gezet, en ook dat werkte meteen. Het enige waar ik daar tegenaan liep is dat hij geen default storage class zet; da's een makkelijke fix, maar wel iets om even rekening mee te houden.

Enkele verschillen t.o.v. K3s:

• Master draait niet vanzelf mee als worker, dat voelt iets netter aan.
• Setup met k0sctl en een config file is stompzinnig makkelijk, en gebruikt een beetje de "ansible aanpak".
• De k0sctl tool heeft nog wat polishing nodig, maar werkt op zich prima als je de juiste randvoorwaarden hebt.
• Een k0s cluster heeft voor mijn use cases betere defaults (geen ingress of lb).
• K0s lijkt in rust wat minder CPU te gebruiken. De master en alle nodes zitten op zo'n 5 tot 7% van één core (op een i5-9400T).
• Bonus verschil: OpenEBS voor simpele workloads lijkt een stuk minder overhead te hebben dan Longhorn. De UI van Longhorn is dan wel weer fijn.

@Mars Warrior bedankt voor de tip, zoals het nu werkt zie ik zeker wel voordelen ten opzichte van K3s.

[Voor 43% gewijzigd door TweakMDS op 02-05-2021 10:06]

[cODAR]

Is er iemand hier die ervaring heeft met het opzetten van Traefik in combinatie met Authelia?

[TweakMDS]

cODAR schreef op dinsdag 4 mei 2021 @ 14:25:
Is er iemand hier die ervaring heeft met het opzetten van Traefik in combinatie met Authelia?

Nog niet, maar ik was wel van plan om iets vergelijkbaars op te zetten met Keycloak. Authelia lijkt op zich wel precies te voldoen aan wat ik wil, dus ik zal er eens mee spelen. De helm chart is nog wel heel erg in beta, en verdere documentatie mist volledig (?), dus het zal hier en daar wat trial & error zijn.

[Mars Warrior]

TweakMDS schreef op dinsdag 4 mei 2021 @ 16:00:
[...]
Nog niet, maar ik was wel van plan om iets vergelijkbaars op te zetten met Keycloak. Authelia lijkt op zich wel precies te voldoen aan wat ik wil, dus ik zal er eens mee spelen. De helm chart is nog wel heel erg in beta, en verdere documentatie mist volledig (?), dus het zal hier en daar wat trial & error zijn.

Ik heb Keycloak eerder getest in een docker swarm omgeving. Het kan veel, maar nam bij mij bijna 2GB ram in beslag. Altijd leuk die Java programma’s...

Authelia heeft wel documentatie icm Traefik, maar dat gaat voornamelijk over de labels vziw.

[TweakMDS]

Mars Warrior schreef op dinsdag 4 mei 2021 @ 16:06:
[...]

Ik heb Keycloak eerder getest in een docker swarm omgeving. Het kan veel, maar nam bij mij bijna 2GB ram in beslag. Altijd leuk die Java programma’s...

Authelia heeft wel documentatie icm Traefik, maar dat gaat voornamelijk over de labels vziw.

Keycloak is inderdaad vrij heftig, maar zit ook wel als full feature product erg goed in elkaar. Authelia kende ik nog helemaal niet, maar integratie met Traefik is inderdaad welkom.

[appollonius333]

cODAR schreef op dinsdag 4 mei 2021 @ 14:25:
Is er iemand hier die ervaring heeft met het opzetten van Traefik in combinatie met Authelia?

Misschien dat Techno Tim je hierbij kan helpen, die heeft recent nog een video hierover gemaakt (mocht het nog niet gelukt zijn).
YouTube: 2 Factor Auth and Single Sign On with Authelia

Zijn er toevallig ook mensen die een OKD cluster draaien en daarop een 'worker' node hebben toegevoegd?

[Voor 10% gewijzigd door appollonius333 op 07-06-2021 20:23]

[TweakerVincent]

tof topic. Ik ben bezig bij de klant een k8s cluster op te zetten (on prem dus). Eindelijk gelukt (thuis draai ik zelfde setup in miijn proxmox setup)

triple loadbalancer met HAproxy en keepalived dus met VIP

triple master CentOs 7
triple worker CentOs 7

hoop uitzoekwerk, maar met Kubespray werkt het eindelijk goed.

Kwam alleen vandaag nog tegen iets dat de CentOs machines 2 harddisks hebben en ik per ongeluk hier geen rekening mee gehouden heb. Kan ik dit snel fixen? Of moeten we servers opnieuw gedeployed worden?

[Douweegbertje]

TweakerVincent schreef op maandag 27 december 2021 @ 18:47:
tof topic. Ik ben bezig bij de klant een k8s cluster op te zetten (on prem dus). Eindelijk gelukt (thuis draai ik zelfde setup in miijn proxmox setup)

triple loadbalancer met HAproxy en keepalived dus met VIP

triple master CentOs 7
triple worker CentOs 7

hoop uitzoekwerk, maar met Kubespray werkt het eindelijk goed.

Kwam alleen vandaag nog tegen iets dat de CentOs machines 2 harddisks hebben en ik per ongeluk hier geen rekening mee gehouden heb. Kan ik dit snel fixen? Of moeten we servers opnieuw gedeployed worden?

Deels uit interesse en deels uit merkwaardigheid; je hebt wat gedaan thuis en moet nu een productie omgeving K8s baremetal bij een klant opleveren? Ik bedoel, zeker tof dat het is gelukt en daarvoor Kudos maar het neergooien is vaak het probleem niet

Anyhow, worker nodes zou je gewoon als cattle moeten zien in het "pets vs cattle" verhaal. Dus, whatever dat je wilt.
Verder is het niet duidelijk wat je wilt met je harddisks. Gewoon node storage as is, node storage voor de pass through vanuit je pods of?

Persoonlijk wil ik zelf nooit stateful op baremetal maar als ik het zou doen, dan via een storage pool. Bijv. onderliggend provisionen via een hypervisor met een storageclass of op K8s met een Rook (Ceph) setup.

Edit; met zo'n kleine setup zou je ook K3s kunnen overwegen btw ^^

[TweakerVincent]

Douweegbertje schreef op dinsdag 28 december 2021 @ 03:39:
[...]


Deels uit interesse en deels uit merkwaardigheid; je hebt wat gedaan thuis en moet nu een productie omgeving K8s baremetal bij een klant opleveren? Ik bedoel, zeker tof dat het is gelukt en daarvoor Kudos maar het neergooien is vaak het probleem niet

Anyhow, worker nodes zou je gewoon als cattle moeten zien in het "pets vs cattle" verhaal. Dus, whatever dat je wilt.
Verder is het niet duidelijk wat je wilt met je harddisks. Gewoon node storage as is, node storage voor de pass through vanuit je pods of?

Persoonlijk wil ik zelf nooit stateful op baremetal maar als ik het zou doen, dan via een storage pool. Bijv. onderliggend provisionen via een hypervisor met een storageclass of op K8s met een Rook (Ceph) setup.

Edit; met zo'n kleine setup zou je ook K3s kunnen overwegen btw ^^

Zo spannend is k8s toch niet? Het werkt allemaal prima bij de klant (TST nu), toevallig vandaag Ingress met triple externe HAProxy loadbalancers goed werkend gekregen met certificaat etc. Al onze API's draaien al. Ja wel bizar veel uitzoekwerk maar niet echt moeilijk.

Volgende week PRD werkend krijgen maar dat is easy.

Ik moet nog even kijken naar de CentOs machines die een 2e hdd hebben. Wil die 2e hdd gebruiken voor alles.

Kubespray werkt prima, beetje jammer dat er een bug in remove script zat, maar laatste versie werkt

[Voor 4% gewijzigd door TweakerVincent op 04-01-2022 18:41]

[TweakMDS]

Ik heb weer eens een verse distro geprobeerd: Talos
Het is een oplossing die net wat anders werkt, omdat het gewoon een OS distributie is volledig zonder CLI.

Werkt prima, inclusief storage met MayaStor. Het enige wat me eraan stoort - en tegenhoudt om echt te gebruiken is de CPU usage...


Aangezien MayaStor het enige is wat erop draait lijkt het erop dat die vooral de CPU usage veroorzaakt.
Wat verder zoeken, en dan lijkt het alsof dat min of meer "by design" is: https://githubmate.com/repo/openebs/Mayastor/issues/828
Blijkbaar vereist MayaStor een volledige CPU core om te pollen. Dat maakt het enigszins onbruikbaar in mijn use-case (energie zuinige home-lab).

Heeft iemand anders hier Mayastor al eens gebruikt? Het lijkt me wel jammer als dit de enige mogelijkheid is, want verder vind ik het een mooie oplossing die een hoog performance potentieel heeft.

Edit: terug naar k0s + longhorn, verder zelfde setup (maar 4GB ipv 6GB per worker) in rust:

Dat past toch wat beter bij mijn homelab setup.

[Voor 15% gewijzigd door TweakMDS op 11-01-2022 12:11]

[Theetjuh]

Ik ben bezig om een k3s cluster te bouwen, maar ik strand helaas nu al op het punt dat ik dualstack (IPv4&IPv6) niet aan de praat krijg.

Ik heb het met k3s 1.22 geprobeerd met calico en ingress-nginx, maar volgens mij is dat niet meer nodig sinds verse 1.23 is uitgekomen.
Hieronder even de stappen en config welke ik heb gevolgd, hopelijk dat iemand me in de juiste weg kan leiden

k3s install:

code:

curl -sfL https://get.K3S.io | K3S_TOKEN="xXxXxXxXxXx" INSTALL_K3S_VERSION=v1.23.4+k3s1 INSTALL_K3S_EXEC="server --disable=servicelb --disable metrics-server --disable-cloud-controller --bind-address 0.0.0.0 --disable-network-policy --cluster-cidr=10.42.0.0/16,fd42::/56 --service-cidr=10.43.0.0/16,fd43::/112 --node-ip=192.168.x.91,x:x:x:x:adb6:47a6:b7ef:992b" sh -s - --cluster-init

configure traefik for dualstack:

code:

sudo kubectl apply -f traefik/config.yaml

code:

apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    service:
      spec:
        ipFamilyPolicy: RequireDualStack

metallb install:

code:

sudo kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.12.1/manifests/namespace.yaml
sudo kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.12.1/manifests/metallb.yaml
sudo kubectl apply -f metallb/config.yaml

code:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.x.80-192.168.x.89
      - x:x:x:x:x:ffff:c0a8:0e50-x:x:x:x:x:ffff:c0a8:0e59
      - 192.168.x.94-192.168.x.99
      - x:x:x:x:x:ffff:c0a8:0e5e-x:x:x:x:x:ffff:c0a8:0e63

Ik kan wel het IPv4 address van 'service/traefik' pingen, maar helaas niet het IPv6 address.
Op de node zelf, kan ik pod waar de service naar verwijst wel pingen op zowel IPv4 en IPv6.

[Theetjuh]

Het werkte dus gewoon, geen idee waarom ik het IPv6 adres van Traefik niet kan pingen, maar als ik daarna een service aanmaak voor m’n pihole, werkt het zonder issues.
Nu door met de rest

[Falcon]

Voor een greenfield project vanuit mijn werkgever maken wij nu gebruik van Azure Container Apps (preview feature). Dit is een PaaS dienst vanuit Microsoft, zodat je zelf niet je AKS/K8 cluster hoeft te beheren.

Wij hopen hierdoor meer te kunnen focussen op het toevoegen van waarde voor de klant, dan met technical maintenance.

Geen aandelen MS hier, maar gewoon een tevreden gebruiker van deze relatief nieuwe feature van Azure.

[Voor 4% gewijzigd door Falcon op 05-04-2022 12:22]

[TweakerVincent]

Ik heb een CentOs 7 worker die opeens geen network meer had vandaag. Kon alleen maar ESXI reset doen, SSH erin lukte niet. de 2 andere workers werkte wel gewoon door.

logs in CentOs tonen weinig. Ik tast in het duister.

Gebruik ContainerD.

Iemand een idee hoe ik kan troubleshooten? Na reset werkt hij perfect.

3 Masters, 3 workers.

Zou het vmware tools kunnen zijn die mss loopt te storen? Ik heb 50 pods erop draaien. Niet erg veel dus. (RAM/CPU is genoeg)

[Voor 21% gewijzigd door TweakerVincent op 16-08-2022 20:21]

[Falcon]

Op dit moment ligt AKS/Azure Container Apps services plat op Azure ivm een Ubuntu bug: https://bugs.launchpad.ne...urce/systemd/+bug/1988119

https://status.azure.com/nl-nl/status

[Voor 12% gewijzigd door Falcon op 30-08-2022 11:28]

[Douweegbertje]

Falcon schreef op dinsdag 30 augustus 2022 @ 11:28:
Op dit moment ligt AKS/Azure Container Apps services plat op Azure ivm een Ubuntu bug: https://bugs.launchpad.ne...urce/systemd/+bug/1988119

https://status.azure.com/nl-nl/status

au

Dat is wel pijnlijk zo.

[Falcon]

Douweegbertje schreef op dinsdag 30 augustus 2022 @ 15:28:
[...]


au

Dat is wel pijnlijk zo.

Ja ongelooflijk dit en nog steeds is het zo ... QA procesje mag wel even aangepast gaan worden daar en bij Ubuntu. Allemaal dankzij een vulnerability update bij Ubuntu, die zonder testen door is gezet naar de productie omgevingen van Azure.

[Voor 15% gewijzigd door Falcon op 30-08-2022 16:01]

[Douweegbertje]

Falcon schreef op dinsdag 30 augustus 2022 @ 16:00:
[...]


Ja ongelooflijk dit en nog steeds is het zo ... QA procesje mag wel even aangepast gaan worden daar en bij Ubuntu. Allemaal dankzij een vulnerability update bij Ubuntu, die zonder testen door is gezet naar de productie omgevingen van Azure.

Mja, heb je als klant geen keuze hoe je update? Ik bedoel ik gebruik geen Azure, maar bij AWS bepalen wij zelf welke AMI (Amazon Machine Image) wordt gebruikt bijvoorbeeld.

[Falcon]

Douweegbertje schreef op dinsdag 30 augustus 2022 @ 16:05:
[...]


Mja, heb je als klant geen keuze hoe je update? Ik bedoel ik gebruik geen Azure, maar bij AWS bepalen wij zelf welke AMI (Amazon Machine Image) wordt gebruikt bijvoorbeeld.

Het gaat hierom platformdiensten die MS zelf levert. Het beheer uit handen geven is juist 1 van de sellingpoints, zodat je dat als ontwikkelteam zelf niet hoeft te doen.

[Douweegbertje]

Falcon schreef op dinsdag 30 augustus 2022 @ 16:08:
[...]


Het gaat hierom platformdiensten die MS zelf levert. Het beheer uit handen geven is juist 1 van de sellingpoints, zodat je dat als ontwikkelteam zelf niet hoeft te doen.

hm ok, ja dat is vrijwel identiek bij AWS, de controlplane is managed maar je worker nodes niet. Lijkt mij namelijk ook erg vervelend als er zomaar wordt geupgrade (exhibit a). Niet alleen voor bugs maar stel dat je een andere version van K8s krijgt die niet compatible is nog met jouw meuk?

[Falcon]

Douweegbertje schreef op dinsdag 30 augustus 2022 @ 16:11:
[...]


hm ok, ja dat is vrijwel identiek bij AWS, de controlplane is managed maar je worker nodes niet. Lijkt mij namelijk ook erg vervelend als er zomaar wordt geupgrade (exhibit a). Niet alleen voor bugs maar stel dat je een andere version van K8s krijgt die niet compatible is nog met jouw meuk?

Wij maken daarom gebruik van Azure Container Apps. Dit is nog een laag boven AKS, als een soort PaaS dienst. Wij kunnen ons volledig hierdoor focussen op ontwikkeling i.p.v. enig-zins na te denken over de inrichting op AKS/K8s.

Maar dus wel afhankelijk.

[Douweegbertje]

Falcon schreef op dinsdag 30 augustus 2022 @ 16:16:
[...]


Wij maken daarom gebruik van Azure Container Apps. Dit is nog een laag boven AKS, als een soort PaaS dienst. Wij kunnen ons volledig hierdoor focussen op ontwikkeling i.p.v. enig-zins na te denken over de inrichting op AKS/K8s.

Maar dus wel afhankelijk.

Right, ok dat klinkt logisch.
Hoop dat het snel is opgelost

[Furion2000]

Momenteel bezig met de steep learning curve en zit even op een dood punt.

Middels minikube en Helm draai ik lokaal een cluster met daarin

• Ingress service
• UI angular service
• Backend kotlin service
• DB postgres service

Ik wil dit en nog een angular webapp gaan deployen op een kubernetes cluster (voor het leren & hosten) en wil daarom de kosten laag houden. Nadat ik dacht, laat ik het op GKE deployen, schrok ik bij het invoeren van de specs van de prijs (160 dollar pm). Nu na een middagje lezen ben ik uitgekomen op

• Digital ocean 2 nodes (master / worker) 24 euro
• Loadbalancer 12 euro
• totaal 36 euro per maand

Voor 'wat geloadbalance' vind ik 12 euro best prijzig en vond ik vervolgens external DNS ( https://github.com/kubernetes-sigs/external-dns ) en vraag ik mij nu af of dit kan werken.

Daarnaast vraag ik mij ook af of thuis een server opzetten niet beter zal zijn als je op zoek bent naar low-cost oplossing met kubernetes voor een 2 tal websites met low-traffic.

Weet niet of jullie mij kunnen helpen met een 'reactie in de juiste richting' ? Momenteel vind ik het vooral lastig om tussen de tutorials met geheime agenda om je naar een oplossing te duwen een goed beeld te krijgen.

[Mars Warrior]

[g1n0]

Furion2000 schreef op zondag 4 december 2022 @ 17:14:
…
Weet niet of jullie mij kunnen helpen met een 'reactie in de juiste richting' ? Momenteel vind ik het vooral lastig om tussen de tutorials met geheime agenda om je naar een oplossing te duwen een goed beeld te krijgen.

Wat is je vraag? Vrij onduidelijk waarop je een reactie wilt.

Toch een poging: Je bent niet afhankelijk van derden, kan ook allemaal op thuisservertjes. Scheelt geld (wat de rode draad in je post lijkt te zijn)

Daarnaast zou dit (indien je duidelijke vragen stelt) beter in een eigen topic kunnen imho

[Furion2000]

g1n0 schreef op zondag 4 december 2022 @ 18:11:
[...]

Wat is je vraag? Vrij onduidelijk waarop je een reactie wilt.

Toch een poging: Je bent niet afhankelijk van derden, kan ook allemaal op thuisservertjes. Scheelt geld (wat de rode draad in je post lijkt te zijn)

Daarnaast zou dit (indien je duidelijke vragen stelt) beter in een eigen topic kunnen imho

haha will do, terwijl ik met de beste bedoeling het kubernetes topic koos

[Jazzy]

Furion2000 schreef op zondag 4 december 2022 @ 20:19:
[...]


haha will do, terwijl ik met de beste bedoeling het kubernetes topic koos

Modbreak:

Ik zou niet weten waarom dat hier niet kan, je vraag is on-topic en is ook weer niet zo specifiek dat er een apart topic voor nodig is. Die ga ik dus weer sluiten, we gaan gewoon hier verder.

[Furion2000]

@g1n0

Toch hier verder dus. Zal proberen het beter te verwoorden.

Klopt, kosten zijn nu even de rode draad in dit verhaal. Het is vooral voor het leren en hobby met 2 sites beide low-traffic waarvan er 1 voor een lokale club is. Met 0 inkomsten hiervoor wilde ik er rond de 35 euro pm kwijt voor zijn.

Dus je zegt dat thuisservertjes toch wel op 1 staan wat betreft kosten? Heb je wellicht een goede source waar ik mijzelf verder kan inlezen? Dit kan ook prima meegroeien met verdere interesses en wat serieuzere ontwikkelprojectjes in de toekomst?

Daarnaast had ik een vraag over Digital Ocean, wat de goedkoopste lijkt na vergelijking met GKE en AWS. Heb ik die DO loadbalancer dan ook nodig of is zo'n External DNS een mooie workaround?

Sowieso op zoek naar goede sources voor een goede setup, want veel google hits die ik vind willen je vooral een bepaalde richting op sturen.

[Voor 6% gewijzigd door Furion2000 op 04-12-2022 21:08]

[g1n0]

Furion2000 schreef op zondag 4 december 2022 @ 21:05:
@g1n0
…

Mits je stroom gratis is door bijv zonnepalen oid. Die berekening kan je zelf het beste maken. Kijk naar het verbruik van je beoogde server, indien je die nog niet hebt is het “Zuinige server topic” hier ook wel interessant.
Daarnaast zijn er ook bij allerlei aanbieders free tiers. Dan kan je gratis met een single node clustertje beginnen te spelen. Vooral als je weinig load hebt kan dit geen kwaad om te experimenteren.
Ben je ook gelijk van je loadbalancer probleem af.

En een goede tutorial heb ik niet voor je. Maar mij heeft Rancher/RKE heel veel geholpen bij het opzetten van mn eerste clusters. Je leert de basis vrij gemakkelijk omdat het voor wordt gedaan, en dan kan ke daarna dieper in de materie gaan.

[bartvb]

K8s is niet gemaakt om goedkoop te zijn. Het is flinke overkill voor het hosten van 2 low traffic sites, eigenlijk de enige goede reden om hiervoor k8s te gebruiken is de leerervaring.

Als je iets goedkoops zoekt dat niet thuis draait dan is LKE misschien een optie?
https://www.linode.com/products/kubernetes/

Control plane is daar gratis, nodes zijn ook vrij betaalbaar.

Je kan ook nog eens kijken naar Azure. Als ik het me goed herinner is je eerste control plane daar ook gratis en ze hebben spot nodes die erg goedkoop zijn (hoewel een spot node weer niet ideaal is om Postgres op te draaien).