När en app fungerar i Docker men klustret lokalt beter sig annorlunda blir felsökningen snabbt en jakt mellan container och Kubernetes. Rancher Desktop kan ge dig båda miljöerna på samma dator, men valet av containerhanterare påverkar vilka kommandon och bilder som faktiskt fungerar.
Välj Rancher Desktop efter hur du bygger och testar
- Kubernetes: lokalt k3s-kluster och verktyg för containerutveckling i samma app.
- Docker CLI och Compose: välj dockerd (Moby) om arbetsflödet bygger på kommandot docker.
- containerd: välj det tillsammans med nerdctl om du vill ligga nära Kubernetes runtime.
- Viktig fallgrop: bilder och arbetslaster följer inte med när du byter containerhanterare.
Rancher Desktop passar bäst när du behöver ett lokalt Kubernetes-kluster
En lokal Kubernetes-miljö är användbar när du vill testa manifest, tjänster och nätverk innan de går vidare till ett kluster i molnet. Rancher Desktop kör Kubernetes med k3s, en lättviktsdistribution, och kan även hantera fristående containrar. Appen finns för macOS, Windows och Linux enligt Rancher Desktop-dokumentationen.
Det gör verktyget mer relevant för den som faktiskt utvecklar eller felsöker Kubernetes-arbetslaster än för den som bara vill starta en enstaka databascontainer. Jag tycker att den inbyggda Kubernetes-miljön är det starkaste skälet att välja det; behöver du bara Docker-kommandon kan en enklare containerlösning passa bättre.
Välj dockerd för Docker-kommandon och containerd för nerdctl
Här avgör ett inställningsval om dina vanliga kommandon fungerar. Med dockerd (Moby) använder du Docker CLI och Docker API. Med containerd använder du i första hand nerdctl, ett Docker-liknande kommandoradsverktyg för containerd. Bara en runtime är aktiv åt gången, enligt inställningsguiden för container engine.
| Din situation | Vad valet innebär | Gör så här |
|---|---|---|
| Projektets instruktioner använder docker och Docker Compose | De förutsätter normalt Docker CLI och API | Välj dockerd (Moby) och kontrollera att kommandona pekar mot rätt miljö |
| Du vill använda containerd och nerdctl | Containerd har egna bildnamnrymder | Välj containerd och använd rätt namespace när Kubernetes behöver se bilden |
| Du byter från den ena runtime-inställningen till den andra | Bilder och arbetslaster är inte tillgängliga på den nya runtime-miljön | Planera för att hämta eller bygga bilder på nytt efter bytet |
Den mindre uppenbara fällan med containerd är dess namespace, alltså en avgränsad plats där bilder lagras. nerdctl lägger som standard bilder i namespace default, medan Kubernetes använder k8s.io; en bild som byggts i den första syns därför inte automatiskt i klustret. Använd nerdctl --namespace k8s.io när bilden ska vara tillgänglig för Kubernetes, enligt guiden om att arbeta med bilder.
Kontrollera detta innan du installerar eller byter
Installationen kan se färdig ut medan den första starten fortfarande hämtar Kubernetes-bilder. På macOS och Windows anger dokumentationen 8 GB minne och 4 CPU-kärnor som rekommendation, och Windows-installationen kräver WSL. Linux kräver bland annat åtkomst till virtualisering via KVM. Kontrollera kraven för just ditt operativsystem i installationsguiden.
Om något inte fungerar är det oftast bättre att kontrollera den specifika miljön än att direkt installera om allt. Tabellen skiljer på symptom som lätt blandas ihop:
| Situation eller symptom | Trolig orsak | Gör så här |
|---|---|---|
docker-kommandon hittar ingen daemon |
containerd är vald i stället för dockerd (Moby) | Kontrollera runtime-valet och starta om miljön vid behov |
| Kubernetes hittar inte en lokalt byggd bild | Bilden ligger i ett annat nerdctl-namespace | Bygg eller tagga bilden i k8s.io, eller använd rätt namespace när du bygger |
| En tjänst svarar inte från värddatorn | Portvidarebefordran eller tjänstens exponering är inte konfigurerad som du tror | Kontrollera tjänstens portar och Rancher Desktops portvidarebefordran |
| Klusteråtkomst saknas på Linux | Användarkontot saknar åtkomst till /dev/kvm |
Kontrollera läs- och skrivrättigheter för KVM innan du felsöker Kubernetes |
Byt runtime med en plan för bilderna
Ett runtime-byte är lätt att göra i inställningarna, men kan överraska om projektets bilder bara finns i den gamla miljön. Rancher Desktop håller inte bilder och arbetslaster gemensamma mellan containerd och dockerd. Räkna därför med att bygga eller hämta bilder igen efter bytet, och se till att viktiga data finns utanför den lokala miljön innan du ändrar konfigurationen.
En användbar tumregel är enkel: behåll dockerd om teamets skript, Compose-filer eller utvecklingsverktyg förutsätter Docker API; välj containerd om du vill arbeta med nerdctl och förstå Kubernetes närmare. Om behovet främst är att testa Kubernetes-manifest, slå på klustret; om du bara behöver köra containrar kan Kubernetes stängas av för att minska resursåtgången.
Gör den lokala miljön lik produktionen där det räknas
Rancher Desktop ger dig en lokal plats att testa, men den ersätter inte kontroll i målmiljön. Skillnader i Kubernetes-version, nätverk, lagring och behörigheter kan fortfarande påverka resultatet. Börja med samma runtime och en kompatibel Kubernetes-version som projektet använder, så blir den första felsökningsrundan mindre rörig.
Om Docker CLI är en förutsättning i arbetsflödet blir dockerd (Moby) det raka valet. Om du däremot vill testa containerd-flödet som Kubernetes använder, välj containerd och håll koll på bildens namespace. Då slipper du den klassiska situationen där bilden finns på datorn, men inte där klustret letar.