Kubernetes portainer kommt nicht aus dem Pending status

[sascha-sphw]

Ich setze ein Kubernetes / Docker cluster wie folgt auf.

Dependencies:

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl

Docker:

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
sudo echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update -y
sudo apt-get install docker-ce docker-ce-cli containerd.io

Kubernetes:

echo br_netfilter | sudo tee /etc/modules-load.d/k8s.conf
printf "net.bridge.bridge-nf-call-ip6tables = 1\nnet.bridge.bridge-nf-call-iptables = 1\n" | sudo tee /etc/sysctl.d/k8s.conf
sudo sysctl --system
 
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
sudo echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

Dann initialisiere ich den cluster

kubeadm init --apiserver-advertise-address=<public_ip> --pod-network-cidr=<private_network>  --ignore-preflight-errors=all

Dann kommt portainer hinzu

kubectl apply -n portainer -f https://raw.githubusercontent.com/portainer/k8s/master/deploy/manifests/portainer/portainer.yaml

Wenn ich mir jetzt den Portainer pod anschaue, sehe ich nur den Status pending.

root@sphw:~# kubectl get pods -n portainer
NAME                         READY   STATUS    RESTARTS   AGE
portainer-59f798c579-cgnsx   0/1     Pending   0          9m53s

Leider habe ich keine Möglichkeit gefunden wie ich herausfinden kann, warum Portainer hier nicht startet. Alles was ich finden konnte ist, dass Kubernetes scheinbar nicht genügend Ressourcen hat, die Maschine hat aber die Mindestanforderung die von Kubernetes gestellt wird. 2CPU's 2GB RAM.

kubectl get events

bringt leider auch keine brauchbaren Informationen.

Vielleicht mach ich auch beim installieren etwas grundlegend falsch, aber ich habe mich eigentlich an der Doku orientiert.

Installing kubeadm

This page shows how to install the kubeadm toolbox. For information on how to create a cluster with kubeadm once you have performed this installation process, see the Creating a cluster with kubeadm page. This installation guide is for Kubernetes v1.33. If you want to use a different Kubernetes...

kubernetes.io

Hat jemand eine Idee, warum Portainer nicht startet, oder wie ich mehr Infos bekommen kann, warum dem so ist?

 

[sascha-sphw]

Ich habe auch folgendes versucht (https://kubernetes.io/docs/tasks/debug-application-cluster/debug-application/).

root@sphw:~# kubectl describe pods portainer-59f798c579-cgnsx
Error from server (NotFound): pods "portainer-59f798c579-cgnsx" not found

 

[sascha-sphw]

Ich habe das gerade mal mit einer 4G RAM Maschine versucht, geht auch nicht, also Arbeitsspeicher kann ich ausschließen.

 

[d4f]

Leider habe ich keine Möglichkeit gefunden wie ich herausfinden kann, warum Portainer hier nicht startet.

Pending bedeutet schlicht dass eine Voraussetzung nicht erfüllbar ist. Die ersten Kandidaten zur Prüfung:
- gibt es ein physical volume claim (PVC) der nicht im Ready-State ist (zB fehlendes/unpassendes PV)
- ist das Image erreichbar?
- erfüllt mindestens ein Worker mit den verfügbaren Ressourcen die Mindest-Anforderung des Containers (spec.containers.resources.requests)
- bei neuen Cluster: können andere Container scheduled werden (zB mariadb ephemeral als Test) oder ist die Maschine durch taints (bspw Master) ausgeschlossen?

bringt leider auch keine brauchbaren Informationen.

Hast du "kubectl get events" und "kubectl describe pods" mit "--all-namespaces" oder "-n portainer" ausgefürt oder im Voraus den Namespace selektiert? Im Default-Namespace sollte sehr wenig liegen und laut "kubectl get pods -n portainer" ist das mal für Portainer eben der Fall.

Anmerkung: mit 4GB machst du mit Kubernetes keine grossen Sprünge sogar wenn nur eine einzelne Machine deployed ist. Eine halbwegs vernünftige Cluster-Struktur braucht schlicht Unmengen an Ram und macht schlicht darunter keinen Spass. Sofern du nicht spezifisch mit Kubernetes experimentieren willst, ist docker/podman/... empfehlenswerter weil am Ende wenigstens noch Ressourcen übrig sind für die Applikation. Nicht falsch verstehen; Kubernetes ist eine super Plattform, aber die Ressourcenanfangskosten sind einfach gigantisch... skalieren dafür aber danach sehr linear.

 

[sascha-sphw]

Hast du "kubectl get events" und "kubectl describe pods" mit "--all-namespaces" oder "-n portainer" ausgefürt

Haha! Ja ich war so naiv und dachte ich bekomme alles wenn ich nichts angebe.

root@sphw:~# kubectl get events -n portainer
LAST SEEN   TYPE      REASON              OBJECT                            MESSAGE
27s         Warning   FailedScheduling    pod/portainer-59f798c579-g7495    0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims.
6m49s       Normal    SuccessfulCreate    replicaset/portainer-59f798c579   Created pod: portainer-59f798c579-g7495
44s         Normal    FailedBinding       persistentvolumeclaim/portainer   no persistent volumes available for this claim and no storage class is set
6m49s       Normal    ScalingReplicaSet   deployment/portainer              Scaled up replica set portainer-59f798c579 to 1

gibt es ein physical volume claim (PVC) der nicht im Ready-State ist (zB fehlendes/unpassendes PV)

Dann werde ich hier noch weiter Doku lesen und entsprechend weiter machen. Danke!

bei neuen Cluster: können andere Container scheduled werden (zB mariadb ephemeral als Test) oder ist die Maschine durch taints (bspw Master) ausgeschlossen?

Ist der master Standardmäßig ausgeschlossen? Dann könnte das ebenfalls ein Grund sein. Da ich ja erst einmal ein wenig Testen wollte, habe ich noch keine nodes hinzugefügt. Ist es denn best practice den master auszuschließen? Dann gehen ja gleich mal 2G RAM ins Land, ohne einen container laufen zu haben . Da kann ich den Punkt Ressourcen gut nachvollziehen.

Anmerkung: mit 4GB machst du mit Kubernetes keine grossen Sprünge sogar wenn nur eine einzelne Machine deployed ist. Eine halbwegs vernünftige Cluster-Struktur braucht schlicht Unmengen an Ram und macht schlicht darunter keinen Spass. Sofern du nicht spezifisch mit Kubernetes experimentieren willst, ist docker/podman/... empfehlenswerter weil am Ende wenigstens noch Ressourcen übrig sind für die Applikation.

Ich Spiele gerade einfach zum testen herum. Docker/Podman werde ich mir dann auch noch anschauen. Danke für den Tipp!
Denkst Du https://k3s.io/ wäre eine bessere Option in Punkto Ressourcen (Sollte ich mich später doch für Kubernetes entscheiden)?

Mein Ziel ist es mein Deployment zu optimieren/vereinfachen, ich habe einige Applikationen die ich aktuell auf mehreren Cloud Maschinen verteilt habe (ohne Docker usw.). Docker gefällt mir hier schon sehr gut, aber ich möchte gerne auch noch darauf verzichten selbst entscheiden zu müssen, auf welcher Maschine ein Container starten soll/wird plus ich möchte nicht alles wieder umwerfen müssen wenn ich hoch skalieren muss.

 

[d4f]

Ja ich war so naiv und dachte ich bekomme alles wenn ich nichts angebe.

Passiert mir auch noch ständig. In purem Kubernetes kann man den Namespace auch vorauswählen über kubectl config set-context --current --namespace=my-namespace - bei Erweiterungen (Openshift, Rancher, Portainer, ...) gibt es dazu oft eigene CLI.

Dann werde ich hier noch weiter Doku lesen und entsprechend weiter machen. Danke!

Standardempfehlung ist ein NFSv4 Server. Schlechte Performance aber unterstützt alle Zugriffsoptionen (ReadWriteOne, ReadWriteMany) und ist multi-access Fähig.

Ist der master Standardmäßig ausgeschlossen?

Das hängt von der Vorkonfiguration ab, ich habe nur Erfahrung mit Microk8s und OKD. Bei microk8s ist standardmässig der Node stadalone und damit sowohl controlplane als auch dataplane. Bei OKD4 sind die 3 Master der Controlplane vom scheduling aller nicht-Control Pods ausgenommen und für alles was nicht auf die Worker gehört sieht man eine Dritte Kategorie vor, die "Infrastructure" Nodes.
Das kann man über taints (Flags auf den Maschinen) und Tolerations (Flags wo ein Pod laufen darf/soll) steuern.

Dann gehen ja gleich mal 2G RAM ins Land, ohne einen container laufen zu haben

Mit 2GB ist der Master sehr klein dimensioniert, ETCd auf dem Kubernetes für seine State-Control aufsetzt ist sehr RAM-gefrässig. Halbwegs etablierte Kubernetes-Distros setzen ohne Scherz 3x 16GB für die Master als Mindestvoraussetzung voraus und der Cluster wird auch im "Leerlauf" problemlos 2 vCPU belasten - das fünffache wenn man Monitoring-Stacks wie EFK integriert. bei Single-Master Setups ist OOM von ETCd zwar kritisch aber nicht tragisch weil der pod selber hochkommt , aber wenn du Quorum bei einem Triple-Master Setup verlierst, ist gerne mal Handarbeit angesagt.

Ist es denn best practice den master auszuschließen?

Ja, Master haben eine absolut prioritäre Rolle; wenn die Control-Plane gestört ist, kann die Workplane nicht gesteuert werden. Zusätzlich ist eine möglichst grosse Trennung von Arbeit und Administration empfehlenswert.

Denkst Du https://k3s.io/ wäre eine bessere Option in Punkto Ressourcen

Zu K3S kann ich mich mangels Erfahrung nicht äußern, aber MiniKube, MicroK8s und K3S verfolgen zumindest oberflächlich ein ähnliches Ziel.
Es steht wegen der höheren Ram-Optimisierung als MicroK8S und dem Support durch Rancher auf der Todo Liste.

Mein Ziel ist es mein Deployment zu optimieren/vereinfachen, ich habe einige Applikationen die ich aktuell auf mehreren Cloud Maschinen verteilt habe (ohne Docker usw.). Docker gefällt mir hier schon sehr gut, aber ich möchte gerne auch noch darauf verzichten selbst entscheiden zu müssen, auf welcher Maschine ein Container starten soll/wird plus ich möchte nicht alles wieder umwerfen müssen wenn ich hoch skalieren muss.

Schlicht gesagt; an Docker oder podman kommst du nicht vorbei. Händisches Bauen/Korrigieren von Images erfolgt am einfachsten noch immer über docker commit/docker tag / docker push um dann in der Kubernetes Registry zu landen und von dort über die Deployment verteilt zu werden.
Falls dein erklärtes Ziel aber das Steuern von Cluster ist, dann sehe ich keinen Grund mehr als die Basiserfahrung mit Docker/podman zu sammeln, und nicht doch direkt Kubernetes zu verwenden. Persönliche Erfahrung
a) fahre soweit wie möglich über Yaml Konfiguration. Leicht versionierbar, leicht nachverfolgbar, leicht replizierbar
b) erstelle regelmässige Backups der Controlplane-Datenbank (sei es Sqlite wie bei M3S oder ETCD bei Standard-Kubernetes)
c) Egal welche "Flavor", wenn du Kubernetes einmal beherrschst ist der Sprung zwischen den Oberflächen bei bedarf in Zukunft recht einfach

h habe einige Applikationen die ich aktuell auf mehreren Cloud Maschinen verteilt habe (ohne Docker usw.). Docker gefällt mir hier schon sehr gut,

Verschiedene Kubernetes-Flavors unterstützten unterschiedliche Cloud-Provider direkt bis zur Installation, Skalierung, Storage und Loadbalancing. Etwas Recherche im Voraus kann also durchaus nachher Arbeit und Geld sparen =)

 

[sascha-sphw]

Super, Danke für die ganzen Infos! Ich sehe schon, da habe ich mir ja ein ordentliches Fass aufgemacht.

 

[Thunderbyte]

Ich kenne mich lange hier nicht so gut aus wie @d4f (Kompliment für die Tiefe der Beiträge). Sicherlich ist Kubernetes bei größeren Setups sinnvoller und mächtiger, allerdings scheint es auch sehr ressourcenhungrig zu sein.
Eine Alternative zu Kubernetes könnte evtl auch https://docs.docker.com/engine/swarm/ sein.
Vergleich zu Kubernetes: https://www.ionos.de/digitalguide/server/knowhow/kubernetes-vs-docker/ .
Eine "GUI" hätte man auch mit Portainer, man kann Docker mit einem Befehl in den Swarm Mode versetzen.

@d4f : hättest Du da eine Empfehlung oder Erfahrung?

 

[sascha-sphw]

Sicherlich ist Kubernetes bei größeren Setups sinnvoller und mächtiger, allerdings scheint es auch sehr ressourcenhungrig zu sein.

Ja, @d4f hatte das in #4 auch erwähnt.

Eine Alternative zu Kubernetes könnte evtl auch https://docs.docker.com/engine/swarm/ sein.

Das wollte ich mir ohnehin auch noch anschauen. Auch https://k3s.io/ steht noch auf meiner Liste, K3s ist wohl eine Ressourcen optimierte lightweight Version von Kubernetes, aber so wie ich es verstanden habe mit mehr oder weniger dem gleichen Befehlssatz.

 

[d4f]

Eine Alternative zu Kubernetes könnte evtl auch https://docs.docker.com/engine/swarm/ sein.

Persönliche Erfahrungen habe ich nur mit Docker (EE), nicht mit Swarm. Prinzipiell gesehen ist Swarm eine deutlich simpler gestrickte Lösung für die gleiche Aufgabe und löst diese Aufgabe laut meiner Kenntnis auch recht gut. Es gibt aber ein paar störende Punkte für mich
- einige technische Probleme/Risiken welche Kubernetes ablehnt, werden hier vorausgesetzt (Keine Trennung von Dataplane und Controlplane)
- das Produkt hat einen deutlich kleineren Marktanteil und damit weniger Unterstützung/Knowhow
- ein Großteil der Kubernetes-Magie (horizontale und vertikale Skalierbarkeit, hohe Fehlertoleranz, sehr ausgereifte Logiken und flexible Steuerung) fehlen schlicht oder sind deutlich weniger ausgereift
- Docker Swarm ist eher die Lösung für ein spezifisches Problem (Verwalten von Container einer spezifischen Applikation auf spezifischen Hosts), Kubernetes ist eine generelle Lösung für generelle Umgebungen

allerdings scheint es auch sehr ressourcenhungrig zu sein.

Absolut. Fairerweise muss man aber sagen dass ein Teil des Ressourcenhungers von den zugrunde liegenden Technologien wie ETCd, OpenVirtualNetwork, Prometheus, EFK, ... kommen. Diese müssen aber nicht zwingend installiert werden, vollumfänglich installiert werden oder verwendet werden, einige Kubernetes-Distributionen für Homelabs/IOT haben dies gut "entschlackt" (siehe K3S oder MicroK8S oben)

@d4f : hättest Du da eine Empfehlung oder Erfahrung?

Meine Erfahrungen belaufen sich hauptsächlich auf ein "pures" Kubernetes (MicroK8S) und OKD4. Letzteres ist genau wie Rancher eher ein Superset von Kubernetes und bringt eher sehr angenehme und gute Verbesserungen/Vereinfachungen der Arbeitsprozesse als grosse tatsächliche Neuerungen.
Zur Veranschaulichung eines solches RollsRoyce von OKD4: Ein volles Cluster mit Mindestempfehlungen (1 Service, 3 Master, 3 Infrastructure, 2 Worker) setzt mal lockere 34 VM-CPU's, 132GB RAM und ca 650GB Datenspeicher voraus, vom NFS oder Ceph mal abgesehen. Inklusive Logging-Stack wirst du rund 8 belastete CPU-Cores und knapp 220 Pods sehen ohne dass eine einzige Benutzer-Applikation läuft.

aber so wie ich es verstanden habe mit mehr oder weniger dem gleichen Befehlssatz

K3S ist auf Kubernetes-Ebene *soweit* ein klassisches Kubernetes, es bringt nur die ganzen Anbindungen zu Storage-Provisioner (NFS, Ceph, Cloud-Anbieter, ...) oder Worker-Provisioners (hauptsächlich Cloud-Anbieter, aber auch Vmware, ...) nicht mit. Zumindest NFS wäre also als externe Abhängigkeit hinzu zu installieren.
Auf technischer Ebene ist es aber ein Kubernetes kopfüber. Aus ETCd wird Distributed-Sqlite, Logging, Monitoring -> wer braucht das schon... undsoweiter =) Hier geht es vor allem darum die eigentlichen Kubernetes-Fähigkeiten ohne Kubernetes-Ressourcen zu verwenden. Dass man auf Sqlite nicht die von ETCd gewohnten hunderte Operationen/Sekunden und praktische Unzerstörbarkeit erwarten kann, sollte klar sein
MicroK8s ist ein volles Kubernetes aber kompakt in einem Snap gehalten. Anderer Ansatz, anderes Ziel.

Im Grunde darf man nicht vergessen dass Kubernetes ein opensource-Nachbau von Google's "Borg" ist, also die Containerlösung auf der seit Jahren praktisch ganz Google scheduled. Wo leichter Einstieg und Ressourcenoptimisierung gegenüber Leistung und Flexibilität abgewogen werden mussten, ist einem nach einer kurzen Tour schnell klar für was sich die Entwickler entschieden haben

 

[Thunderbyte]

Herzlichsten Dank für diesen tiefen Einblick und Deine Einschätzung.

Da ist "volles" Kubernetes wohl wirklich für sehr große Firmen / Anwendungen geeignet, da kostet die Basis dafür ja auch schon einiges. Puh, die genannten Mindestempfehlungen sind schon sehr ordentlich .

Und für eine persönliche Umgebung (sowas wirds wohl bei @sascha-sphw eher sein) gibt es dann die "kleinen" Varianten.

Swarm wäre dann wohl nur für die Multi-Host Verteilung einer einzigen Anwendung geeignet, wenn ich das richtig verstehe. Gibts auch mitunter, aber flexibler sind die Kubernetes Varianten dann doch. Der Support ist natürlich auch wichtig, da hat wieder Kubernetes die Nase vorne.

 

[sascha-sphw]

Und für eine persönliche Umgebung (sowas wirds wohl bei @sascha-sphw eher sein) gibt es dann die "kleinen" Varianten.

Mein Ziel ist es erst einmal das deployment meiner aktuellen Applikationen zu vereinfachen. Aktuell habe ich 15 Applikationen auf 7 Server verteilt, für Kubernetes sicher zu klein, aber für mich der Aufwand zu groß. Und mit der Zeit werden es ja auch nicht weniger, ich habe viel Ideen die ich noch umsetzen werde darunter auch welche, die als Cloud Service laufen sollen. Ich möchte halt die Arbeit die ich damit habe (wie mit eigentlich allem ), auf ein Minimum reduzieren. Dazu schaue ich mir jetzt einfach alle möglichen Sachen an und spiele damit herum, entscheiden werde ich mich dann für das rundum sorglos Paket.

 

[d4f]

entscheiden werde ich mich dann für das rundum sorglos Paket.

Kubernetes ist ein Rundum-Sorglos Paket wenn du das Hosten anderen (Google GKE, Amazon EKS, ...) überlässt und nur Benutzer (Tenant) der Infrastruktur bist. Das Verwalten von einem eigenen sorgfältig aufgesetzten Kubernetes geht einfacherer als die gleiche Anzahl standalone-Server, aber sie ist garantiert nie auch nur annähernd null.

Aktuell habe ich 15 Applikationen auf 7 Server verteilt, für Kubernetes sicher zu klein

Absolut nicht. Wenn man die technischen Voraussetzungen respektiert (Kubernetes braucht zB externe Loadbalancer und externen Speicher zur vollumfänglichen Nutzung) und bereit ist das System in einem non-best-practice Setup zu betreiben (bspw Master und Worker Roles auf dem gleichen Host), kann man ab 3 Maschinen von einem sinnvollen Cluster reden.

da kostet die Basis dafür ja auch schon einiges. Puh, die genannten Mindestempfehlungen sind schon sehr ordentlich

Vieles kann man weglassen, aber es ist nicht zwingend empfohlen. So gibt es keine technische Verpflichtung die Router, Build-Pods und Logging auf Infrastructure-Nodes zu lagern, Worker können diese Aufgabe problemlos übernehmen. Es ist aber sauberer, wenn Worker tatsächlich nur echte Workloads betreiben und keine Cluster-interne Aufgaben.

Swarm wäre dann wohl nur für die Multi-Host Verteilung einer einzigen Anwendung geeignet, wenn ich das richtig verstehe.

Es ist recht genau das Ziel, ja. Generell Workloads sind technisch möglich aber externe Supersets (Portainer, ...) sind dazu praktisch verpflichtend um es sinnvoll zu verwalten und trotzdem bleibt es weniger flexibel.