Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Acties:
  • +6Henk 'm!

  • Douweegbertje
  • Registratie: mei 2008
  • Laatst online: 00:10

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
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]

My website is secure. https://isitthough.com ?


Acties:
  • +1Henk 'm!

  • ginojo
  • Registratie: maart 2016
  • Niet online
Wellicht is https://rancher.com/ een leuke toevoeging voor beginners.

Acties:
  • 0Henk 'm!

  • Douweegbertje
  • Registratie: mei 2008
  • Laatst online: 00:10

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
ginojo 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!).

My website is secure. https://isitthough.com ?


  • reputatio
  • Registratie: mei 2017
  • Laatst online: 23:05
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
  • Registratie: mei 2008
  • Laatst online: 00:10

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
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 :D 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.

My website is secure. https://isitthough.com ?


  • reputatio
  • Registratie: mei 2017
  • Laatst online: 23:05
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
  • Registratie: mei 2008
  • Laatst online: 00:10

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
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..

My website is secure. https://isitthough.com ?


  • TweakMDS
  • Registratie: mei 2002
  • Laatst online: 27-02 13:30
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
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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.

http://www.team-mediaportal.com/


  • TweakMDS
  • Registratie: mei 2002
  • Laatst online: 27-02 13:30
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
  • Registratie: december 2004
  • Laatst online: 27-02 14:15
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
  • Registratie: mei 2008
  • Laatst online: 00:10

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
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!

My website is secure. https://isitthough.com ?


  • Mars Warrior
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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 _/-\o_

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. 8)

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 ;w

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. :X

http://www.team-mediaportal.com/


  • Douweegbertje
  • Registratie: mei 2008
  • Laatst online: 00:10

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
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 _/-\o_

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. 8)

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 ;w

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. :X
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 :D

My website is secure. https://isitthough.com ?


  • Mars Warrior
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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 :D
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.

http://www.team-mediaportal.com/


  • TweakMDS
  • Registratie: mei 2002
  • Laatst online: 27-02 13:30
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
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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 :D
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 :9

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 :-(

http://www.team-mediaportal.com/


  • TweakMDS
  • Registratie: mei 2002
  • Laatst online: 27-02 13:30
Mars Warrior schreef op zondag 16 augustus 2020 @ 19:34:
Dat is een leuke setup. Ook lekker praktisch :D
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
  • Registratie: februari 2008
  • Laatst online: 22:43
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
  • Registratie: mei 2002
  • Laatst online: 27-02 13:30
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
  • Registratie: februari 2008
  • Laatst online: 22:43
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 :9 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
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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]

http://www.team-mediaportal.com/


  • johnkeates
  • Registratie: februari 2008
  • Laatst online: 22:43
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
  • Registratie: mei 2008
  • Laatst online: 00:10

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
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.

My website is secure. https://isitthough.com ?


  • Mars Warrior
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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 _/-\o_ .

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 ;w

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

http://www.team-mediaportal.com/


  • Falcon
  • Registratie: februari 2000
  • Laatst online: 26-02 07:39

Falcon

Q.A. Engineer (.net/azure)

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]

"You never come second by putting other people first"


  • TweakMDS
  • Registratie: mei 2002
  • Laatst online: 27-02 13:30
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 :o

Ik zit nu trouwens live in KubeCon :)

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


  • Mars Warrior
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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 :o

Ik zit nu trouwens live in KubeCon :)
Gebruik je toevallig dan GitOps en dus ook Flux voor de deployment in combinatie met sealed secrets?

http://www.team-mediaportal.com/


  • TweakMDS
  • Registratie: mei 2002
  • Laatst online: 27-02 13:30
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 :D
(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
  • Registratie: mei 2008
  • Laatst online: 00:10

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
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 :D
(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 :)

My website is secure. https://isitthough.com ?


  • Mars Warrior
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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 _/-\o_

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...

http://www.team-mediaportal.com/


  • Mars Warrior
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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 :X

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

---
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 8)7

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:
1
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:
https://tweakers.net/i/GdeXf-oi_MxT34c4uVII4Zh_BWU=/800x/filters:strip_exif()/f/image/oQFz1VeYCl45jnLL0ixYccxR.png?f=fotoalbum_large

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

http://www.team-mediaportal.com/


  • Douweegbertje
  • Registratie: mei 2008
  • Laatst online: 00:10

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
@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"

My website is secure. https://isitthough.com ?


  • TweakMDS
  • Registratie: mei 2002
  • Laatst online: 27-02 13:30
Mars Warrior schreef op dinsdag 18 augustus 2020 @ 23:06:

Dus @SndBastard , mocht je tijd hebben. Een tutorial is erg fijn :X
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:
1
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:
1
2
3
4
5
6
7
8
9
10
11
12
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
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:
1
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
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

Aha!

k3s:
code:
1
2
3
4
5
6
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:
1
2
3
4
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... _/-\o_

@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 _/-\o_

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 O-)

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

http://www.team-mediaportal.com/


  • TweakMDS
  • Registratie: mei 2002
  • Laatst online: 27-02 13:30
@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
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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]

http://www.team-mediaportal.com/


  • TweakMDS
  • Registratie: mei 2002
  • Laatst online: 27-02 13:30
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
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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 8)7

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:
1
2
3
4
5
6
7
8
9
10
11
12
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:
1
2
3
4
5
6
7
8
9
10
11
12
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 :D

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 O-)

@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 8)

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

http://www.team-mediaportal.com/


  • Mars Warrior
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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 :9~

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 :)F
- 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 *O*

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!

http://www.team-mediaportal.com/


  • TweakMDS
  • Registratie: mei 2002
  • Laatst online: 27-02 13:30
@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
  • Registratie: mei 2008
  • Laatst online: 00:10

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
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 :Y)

My website is secure. https://isitthough.com ?


  • ginojo
  • Registratie: maart 2016
  • Niet online
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
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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

http://www.team-mediaportal.com/


  • Mars Warrior
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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.

http://www.team-mediaportal.com/


  • Douweegbertje
  • Registratie: mei 2008
  • Laatst online: 00:10

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
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.

My website is secure. https://isitthough.com ?


  • Mars Warrior
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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.

http://www.team-mediaportal.com/


  • Douweegbertje
  • Registratie: mei 2008
  • Laatst online: 00:10

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
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 :Y) :>
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 :)

My website is secure. https://isitthough.com ?


  • TweakMDS
  • Registratie: mei 2002
  • Laatst online: 27-02 13:30
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
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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 :F

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 :9~

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 :z

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 :X

Ben er weer ff klaar mee ;w

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

http://www.team-mediaportal.com/


  • Mars Warrior
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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.

http://www.team-mediaportal.com/


  • TweakMDS
  • Registratie: mei 2002
  • Laatst online: 27-02 13:30
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
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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.

http://www.team-mediaportal.com/


  • TweakMDS
  • Registratie: mei 2002
  • Laatst online: 27-02 13:30
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
  • Registratie: mei 2002
  • Laatst online: 27-02 13:30
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
  • Registratie: januari 2012
  • Laatst online: 25-02 14:07
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. :)

~ beware of misinformation.


  • Mars Warrior
  • Registratie: oktober 2003
  • Laatst online: 23:33

Mars Warrior

Earth, the final frontier

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.

http://www.team-mediaportal.com/

Pagina: 1


Apple iPhone 12 Microsoft Xbox Series X LG CX Google Pixel 5 Sony XH90 / XH92 Samsung Galaxy S21 5G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True