Tek sunucuda k3s kurulumu: Ne zaman tercih edilmeli?

k3s nedir ve tek bir düğüm size ne sağlar

k3s, tek bir binary dosyası olarak paketlenmiş tam teşekküllü bir Kubernetes dağıtımıdır. Bunu tek bir VPS üzerinde çalıştırmak, üç makineli bir kontrol düzlemi olmadan gerçek Kubernetes API'sine sahip olmanızı sağlar. Sertifikalı bir Kubernetes dağıtımı olduğu için, burada uygulanan bir manifest dosyası daha sonra yönetilen bir cluster üzerinde de çalışır. Kurulum tek bir komutla yaklaşık bir dakikada tamamlanır. Bunun bedeli, uygulamalarınıza artık ayrılmayan bellek miktarı ve Docker Compose ile asla karşılaşılmayan bir dizi hata modudur.

SUSE, k3s'i uç noktalar ve küçük kurulumlar için geliştirmiştir; upstream Kubernetes'ten farklı olan her özellik, yapıyı küçültmek amacıyla tasarlanmıştır. Varsayılan veri deposu etcd değil, kine adlı bir arayüz arkasında çalışan sqlite'tır; bu sayede yönetilmesi gereken bir etcd çoğunluğu (quorum) yoktur. containerd, ayrı olarak kurulmak yerine binary içine gömülmüştür. Aynı binary dosyası; cluster DNS için CoreDNS'i, ingress controller olarak Traefik'i, bulut sağlayıcı desteği olmadan LoadBalancer servislerinin çalışmasını sağlayan ServiceLB'yi (klipper-lb olarak da bilinir), kalıcı birimler için local-path provisioner'ı, metrics-server'ı ve pod ağ iletişimi için flannel'ı beraberinde getirir. Bunların her biri varsayılan olarak başlatılır. Bu nedenle, aşağıda açıklanan port çakışması, halihazırda başka işler yapan bir VPS üzerindeki en yaygın ilk sorundur.

Tek bir k3s düğümünün yeterli olduğu durumlar

Bu kuralı uygulayın. Kubernetes API'sine ihtiyaç duyduğunuzda k3s çalıştırın: kontrolünüz altındaki bir makinede Kubernetes öğreniyorsanız veya kullanmak istediğiniz yazılım yalnızca bir Helm chart olarak yayınlanıyorsa bu yöntem uygundur. Manifest taşınabilirliği de önemlidir; burada yazdığınız bir Deployment, yönetilen bir kümeye hiçbir değişiklik yapılmadan taşınabilir. Uygulamaların kendisi önceliğiniz olduğunda Docker Compose kullanın. Compose, aynı container'ları çok daha az hareketli parça ile başlatır ve bir VPS üzerinde Compose dosyası, bir yıl sonra bir manifest dizininden çok daha kolay okunur.

Tek bir düğümün size ne sağlamadığını netleştirin.

• Yüksek erişilebilirlik yoktur. VPS yeniden başladığında tüm iş yükleri durur. Kubernetes bir pod'u başka bir düğüme zamanlamaya çalışır ancak başka bir düğüm yoktur.
• Uygulama, tek bir makinede aynı birimi (volume) paylaşan iki replikayı tolere etmediği sürece, servisi ayakta tutan bir rolling update (kademeli güncelleme) yapılamaz.
• Aşağıdaki local-path bölümünde açıklanan nedenlerden dolayı, depolama birimi doğrudan sunucuya bağlıdır.
• Herhangi bir şey dağıtsanız da dağıtmasanız da yaklaşık bir gigabayt RAM tüketen bir kontrol düzlemi (control plane) vardır.

Bunların hiçbiri k3s'i kötü bir tercih yapmaz. Ancak insanların genellikle belirttiği "güvenilirlik" gerekçesi için k3s kötü bir tercihtir. Eğer asıl istediğiniz gerçek bir çok düğümlü küme oluşturmak için birden fazla makine ise, bu karar önceliklidir: Kendi donanımınızda Proxmox ile kiralanan bir VPS karşılaştırması, k3s üzerinde neyin çalışacağına karar vermeden önce düğümlerin nereden geleceğini belirler.

Herhangi bir dağıtım yapmadan önce k3s'in RAM ve CPU maliyeti

k3s projesi tahminler yerine ölçülmüş değerleri yayımlar. Bu değerleri dikkatle okuyun, çünkü insanların telaffuz ettiği rakam boşta çalışan bir k3s'e ait değildir.

[
  {
    "label": "Server, sqlite datastore",
    "ram_mb": "1,596",
    "cpu_percent_of_one_core": 6
  },
  {
    "label": "Server, embedded etcd",
    "ram_mb": "1,606",
    "cpu_percent_of_one_core": 6
  },
  {
    "label": "Agent node only",
    "ram_mb": "275",
    "cpu_percent_of_one_core": 3
  }
]

Bu testteki bir sunucu düğümü, 95. yüzdelik dilimde 1,596 MB RAM ve tek bir çekirdeğin yaklaşık 6 kadarını kullanmıştır. Bunlar yayımlanmış verilerdir, bu rehberdeki ölçümler değildir; test, tüm paketlenmiş bileşenleri etkinleştirilmiş ve üzerine Prometheus ile Grafana izleme yığını eklenmiş k3s v1.26.5 sürümü ile gerçekleştirilmiştir, dolayısıyla bu rakam boş bir küme yerine gerçek bir iş yükünü içerir. sqlite yerine gömülü etcd kullanılması bu değeri 1,606 MB seviyesine taşımıştır. Kontrol düzlemi olmadan yalnızca kubelet ve containerd çalıştıran bir aracı düğüm ise 275 MB kullanmıştır. Bir sunucu için belgelenen minimum değer 2 çekirdek ve 2 GB RAM'dir; bu minimum değer, iş yüklerinizden önce k3s ve paketlenmiş bileşenlerini kapsar.

Pratik okuma şudur: 2 GB'lık bir VPS üzerinde kontrol düzlemi ve beraberinde gelen eklentiler size çok az alan bırakır ve baskı altında gerçekleşecek ilk şey kubelet'in pod'ları tahliye etmesidir. 4 GB, birkaç küçük servis barındıran tek bir düğüm için rahat bir alt sınırdır. Bu rakam da dahil olmak üzere yayımlanmış hiçbir rakama güvenmek yerine kendi sunucunuzu ölçün.

free -h
sudo k3s kubectl top node
sudo k3s kubectl get pods -A

Kurulumdan önce ve kube-system içindeki her pod Running durumuna geçtikten sonra free -h komutunu çalıştırın. Aradaki fark, kontrol düzleminin donanımınızdaki maliyetidir. k3s kubectl top node, kurulumdan sonraki ilk bir veya iki dakika boyunca error: Metrics API not available döndürür, çünkü metrics-server henüz hiçbir veriyi taramamıştır. Bu bir hata değildir. Eğer tek bir sunucuyu hem bu iş hem de aynı anda başka işler için boyutlandırıyorsanız, bir VPS için RAM ve CPU boyutlandırma bölümündeki hesaplamalar burada da aynen geçerlidir.

k3s kurulumunu en son sürüme değil, belirli bir sürüme sabitleme

Herkesin kopyaladığı hızlı başlangıç komutu, çalıştırdığınız gün kararlı (stable) kanalın işaret ettiği sürümü kurar. Uzun süreli kullanmayı planladığınız bir makinede sürümü sabitleyin. k3s, her Kubernetes alt sürümü (minor version) için bir kanal yayınlar; bu nedenle INSTALL_K3S_CHANNEL=v1.36 kullanımı, v1.36 içindeki yama sürümlerini (patch releases) takip eder ve siz istemeden bir alt sürüme geçiş yapmaz. Ağustos 2026 itibarıyla kararlı kanal v1.36.3+k3s1 sürümünü işaret etmektedir.

Önce yapılandırma dosyasını oluşturun, ardından kurulumu gerçekleştirin. k3s, başlatıldığında /etc/rancher/k3s/config.yaml dosyasını okur; bu nedenle dosya içindeki tüm ayarlar ilk açılışta ve sonraki tüm başlatmalarda geçerli olur.

sudo mkdir -p /etc/rancher/k3s
sudo tee /etc/rancher/k3s/config.yaml >/dev/null <<'EOF'
tls-san:
  - k3s.example.com
EOF
curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=v1.36 sh -

Bir kanal yerine tam bir sürümü sabitlemek için INSTALL_K3S_VERSION=v1.36.3+k3s1 kullanın. Artı işareti, etiket adının bir parçasıdır. Ardından servisin ayağa kalkıp kalkmadığını kontrol edin.

k3s --version
sudo systemctl status k3s
sudo k3s kubectl get node
sudo k3s kubectl get pods -A

kubectl get node komutu, yaklaşık otuz saniye içinde Ready durumunda bir düğüm (node) listelemeli ve kube-system içindeki tüm pod'lar Running veya Completed durumuna ulaşmalıdır. NotReady durumunda takılı kalan bir düğüm, genellikle container çalışma zamanının (runtime) başlamadığı anlamına gelir; bu durumda sudo journalctl -u k3s -n 100 --no-pager dosyasını inceleyin. Alışılmadık bir VPS imajı kullanıyorsanız, başka bir hata ayıklama işlemine geçmeden önce sudo k3s check-config komutunu çalıştırın: bu komut, eksik çekirdek özelliklerini raporlar ve günlük kayıtlarını okumaktan çok daha hızlı bir sonuç verir.

80 numaralı port neden kullanımda ve düzeltmek için nelerden vazgeçilmeli

Bu hata, halihazırda bir servis çalıştıran VPS üzerinde kurulum yapanların karşılaştığı bir durumdur. Kurulum başarıyla tamamlanır. Ancak Traefik hiçbir zaman bir adres alamaz ve halihazırda çalışan siteniz çalışmaya devam ettiği için, bir ingress'e erişmeye çalışana kadar hiçbir şey bozuk görünmez.

Mekanizma şöyledir: paket halindeki Traefik chart, 80 ve 443 numaralı portlarda LoadBalancer tipinde bir Service oluşturur. ServiceLB, bu isteği her düğümde hostPort olarak bu port numaralarını talep eden ve svclb- ön ekiyle adlandırılan küçük pod'lardan oluşan bir DaemonSet oluşturarak yanıtlar. hostPort, tıpkı docker run -p 80:80 komutunun yaptığı gibi, container portunu doğrudan düğümün kendi ağ ad alanına (network namespace) yayınlar. Eğer nginx, Caddy, Apache veya başka bir container halihazırda 80 numaralı portu tutuyorsa, çekirdek (kernel) bu portu ikinci kez vermeyecektir; bu nedenle zamanlayıcının (scheduler) pod'u yerleştirecek bir yeri kalmaz.

sudo k3s kubectl -n kube-system get pods
sudo k3s kubectl -n kube-system get svc traefik
sudo ss -lntp '( sport = :80 or sport = :443 )'

svclb pod'unun Pending durumunda kaldığını ve servisin harici bir adresi olmadığını görürsünüz:

svclb-traefik-8f2c1a-r6k9x   0/2   Pending   0   3m
traefik   LoadBalancer   10.43.62.11   <pending>   80:31480/TCP,443:30219/TCP

kubectl -n kube-system describe pod svclb-traefik-... komutunu çalıştırmak, sorunun nedenini doğrudan belirtir:

0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports.

ss -lntp komutu, portu hangi sürecin tuttuğunu size söyler. Bu durumdan kurtulmanın birden fazla yolu vardır ve her birinin bir bedeli bulunur.

Portları k3s'e verin. Mevcut web sunucusunu durdurun ve devre dışı bırakın, ardından 80 ve 443 numaralı portların kontrolünü Traefik'e bırakın. VPS sadece bir k3s sunucusu olacaksa ve sunduğunuz her şey bir Ingress arkasına taşınacaksa, en doğru çözüm budur.

ServiceLB'yi devre dışı bırakın ve mevcut proxy'nizi koruyun. Kurulumu --disable=servicelb ile yapın. LoadBalancer tipindeki bir Service yine de bir NodePort tahsis eder, bu sayede Traefik 31480 gibi yüksek bir port üzerinden erişilebilir kalır ve nginx veya Caddy proxy'niz 127.0.0.1:31480 adresine yönlendirme yapar. Vazgeçtiğiniz şey harici adrestir: servis sürekli olarak <pending> raporlar; bu durum bir tercih olsa da bir hata gibi görünebilir.

Traefik'i devre dışı bırakın ve kendi proxy'nizle yönlendirme yapın. Kurulumu --disable=traefik ile yapın. Bu durumda bir ingress controller'ınız olmaz, dolayısıyla Ingress nesneleri hiçbir işlev görmez: onları izleyen bir controller olmadan API içerisinde beklerler. Bir host proxy'sinden NodePort'lara yönlendirme yapıyorsanız bu kabul edilebilir bir durumdur ve HTTP trafiğinin nasıl yönetilmesi gerektiğini zaten biliyorsanız en dürüst tercihtir. Ön tarafta neyin bulunması gerektiği konusunda kararsızsanız, herhangi bir şeyi devre dışı bırakmadan önce reverse proxy olarak nginx, Caddy ve Traefik arasındaki seçim konusunu netleştirin.

Her iki bayrak da yükleyiciye veya yapılandırma dosyasına eklenmelidir:

tls-san:
  - k3s.example.com
disable:
  - traefik
  - servicelb

Kurulumdan sonra bu dosyayı düzenleyip sudo systemctl restart k3s komutunu çalıştırmak da işe yarar, çünkü --disable sadece kurulum sırasında bir bileşeni atlamaktan fazlasını yapar. Ayrıca halihazırda dağıtılmış bir bileşeni siler, böylece değişiklik çalışan bir küme üzerinde etkili olur.

Traefik'i tutmak ancak chart'ın nasıl yapılandırıldığını değiştirmek istiyorsanız, /var/lib/rancher/k3s/server/manifests/traefik.yaml dosyasını düzenlemeyin. k3s, her başladığında bu dosyayı varsayılan ayarlarla yeniden yazar. Bunun yerine aynı dizine ayrı bir dosya ekleyin, çünkü /var/lib/rancher/k3s/server/manifests içindeki her şey başlangıçta ve disk üzerinde değiştiği her an otomatik olarak uygulanır.

apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    ports:
      web:
        forwardedHeaders:
          trustedIPs:
            - 10.0.0.0/8

Bu örnek, güvenilir proxy adresleri olan tek bir Traefik chart değerini ayarlar. Aynı mekanizma, portları da dahil olmak üzere chart'ın sunduğu diğer tüm değerleri ayarlamak için kullanılabilir.

Tek düğüm üzerinde kalıcı depolama

k3s, Rancher'ın local-path provisioner altyapısını kullanan local-path adında varsayılan bir StorageClass ile gelir. Herhangi bir storageClassName belirtilmeyen PersistentVolumeClaim talepleri bu sınıfı kullanır. Birimler, düğümün kendi diski üzerinde, her birim için bir alt dizin olacak şekilde /var/lib/rancher/k3s/storage yolunda barındırılır.

sudo k3s kubectl get storageclass
sudo k3s kubectl get pvc -A
sudo ls -l /var/lib/rancher/k3s/storage

"Düğümün kendi diski üzerinde" ifadesinin iki sonucu vardır ve her ikisi de bugün değil, ileride sorun yaratır.

StorageClass, volumeBindingMode: WaitForFirstConsumer kullandığı için yeni bir PVC, bir pod onu gerçekten mount edene kadar Pending durumunda kalır. kubectl describe pvc komutu şu çıktıyı verir:

waiting for first consumer to be created before binding

Bu normal bir durumdur; dolayısıyla bir PVC'yi tek başına oluşturup beklemek, durumun değişmesini sağlamaz.

Birime bağlandıktan sonra, birim onu oluşturan düğüme özel bir düğüm yakınlığı (node affinity) kazanır; bu da söz konusu talebi kullanan her pod'u, birimin ömrü boyunca o düğüme sabitler. Tek düğümde bunu fark etmezsiniz. İleride ikinci bir düğüm eklediğinizde, taşınmayı reddeden bir pod, siz kubectl get pv -o yaml komutunu çalıştırıp nodeAffinity içinde ana makine adını görene kadar bir zamanlayıcı hatası gibi görünür.

Yedeklemeler sizin sorumluluğunuzdadır. VPS'i yeniden oluşturmak bu dizini siler; aşağıdaki kaldırma betiği de aynı işlemi yapar. /var/lib/rancher/k3s/storage dizinini ve canlı bir veritabanı olduğu için servis durdurularak kopyalanması gereken /var/lib/rancher/k3s/server/db/state.db yolundaki sqlite veri deposunu yedekleyin. Bunun alternatifi, kümeyi geçici olarak kabul edip her manifest dosyasını git üzerinde tutmaktır.

Ingress ve TLS

Traefik etkin bırakıldığında, standart bir Ingress nesnesi yeterlidir.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt
spec:
  ingressClassName: traefik
  tls:
    - hosts:
        - hello.example.com
      secretName: hello-tls
  rules:
    - host: hello.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: hello
                port:
                  number: 80

Sertifikalar kendiliğinden oluşmaz. Yaygın çözüm, yayınlanmış manifest dosyası üzerinden kurulan cert-manager ve bir adet ClusterIssuer kullanmaktır. Ağustos 2026 itibarıyla güncel sürüm v1.21.1'dir.

sudo k3s kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.21.1/cert-manager.yaml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    email: you@example.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-account-key
    solvers:
      - http01:
          ingress:
            ingressClassName: traefik

HTTP-01 sınaması, ACME (otomatik sertifika yönetim ortamı) sunucusunun genel internet üzerinden http://hello.example.com/.well-known/acme-challenge/... adresine bağlanması anlamına gelir. Bu nedenle DNS A kaydının halihazırda VPS'i işaret etmesi ve 80 numaralı portun Traefik'e ulaşabiliyor olması gerekir. Eğer ServiceLB'yi devre dışı bırakıp kendi proxy'nizi ön tarafa koyduysanız, bu proxy'nin sınama yolunu da iletmesi gerekir; aksi takdirde cert-manager, Challenge nesnesi üzerinde şu hata ile takılı kalır:

Waiting for HTTP-01 challenge propagation: wrong status code '404', expected '200'

Sertifika oluşturma sürecini sudo k3s kubectl describe certificate hello-tls ve sudo k3s kubectl get order,challenge -A komutlarıyla izleyin.

kubeconfig ve API sunucusunun neden özel kaldığı

k3s, yönetici kimlik bilgilerini /etc/rancher/k3s/k3s.yaml dosyasına yazar. Bu dosya varsayılan olarak root kullanıcısına aittir ve 600 izin moduyla oluşturulur. Dosya, cluster-admin yetkilerine sahip bir istemci sertifikası içerir; bu nedenle dosyayı okuyabilen herkes kümenin tam yetkili sahibi olur.

sudo k3s kubectl get node
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
kubectl get node

KUBECONFIG değişkeni ayarlanmamış ayrı bir kubectl kurulumu, k3s ile ilgisi olmayan varsayılan bir konuma yöneldiği için The connection to the server localhost:8080 was refused - did you specify the right host or port? hatası verir. KUBECONFIG değişkenini ayarlayın veya doğru dosyayı otomatik olarak okuyan sudo k3s kubectl komutunu kullanın.

Normal bir kullanıcının kubectl çalıştırabilmesi için --write-kubeconfig-mode 644 komutunun önerildiğini göreceksiniz. Bu komutun ne işe yaradığını anlayın: cluster-admin kimlik bilgilerini makinedeki tüm yerel hesaplar için okunabilir hale getirir. Tek bir yöneticinin bulunduğu bir sistemde bu kabul edilebilir bir takas olabilir. Paylaşımlı bir sistemde ise durum böyle değildir. Dosyayı kopyalamak, kimlik bilgilerini genel erişime açmadan sadece ilgili kullanıcıya erişim sağlar:

mkdir -p ~/.kube
sudo install -o $USER -g $USER -m 600 /etc/rancher/k3s/k3s.yaml ~/.kube/config

Dosya içerisindeki server: satırı https://127.0.0.1:6443 değerini okur. kubectl komutunu dizüstü bilgisayarınızdan kullanmak için 6443 numaralı portu internete açmayın. Herkese açık bir Kubernetes API'si sürekli bir hedeftir; dışarıya açık bir API, küçük kümelerin başkaları için kripto para madenciliği yapmasına neden olan temel güvenlik açığıdır. API'yi SSH üzerinden tünelleyin ve dosyadaki adresi değiştirmeyin:

ssh -N -L 6443:127.0.0.1:6443 user@your-vps
KUBECONFIG=./k3s.yaml kubectl get node

API'ye özel bir ağ adresi üzerinden erişmeniz gerekiyorsa, kurulumu bu ismi veya adresi içeren tls-san parametresiyle yapın, ardından kopyalanan dosyadaki server: satırını buna uygun şekilde düzenleyin. SAN (subject alternative name) girişi olmadan kubectl bağlantıyı reddeder:

x509: certificate is valid for 127.0.0.1, 10.43.0.1, not 203.0.113.10

Bir küme için belgelenen gelen portlar; API için TCP 6443, düğümler arası flannel VXLAN trafiği için UDP 8472 ve kubelet metrikleri için TCP 10250'dir. Tek düğümlü bir kurulumda, bu portların hiçbirinin internete açık olması gerekmez.

containerd, Docker değildir

k3s kendi gömülü containerd sürümünü çalıştırır ve Docker ile ortak bir imaj deposu kullanmaz. docker build ile yeni oluşturduğunuz bir imaj k3s tarafından görülmez; bu nedenle docker images komutu imajı listelese bile pod ErrImagePull hatası verir. İmajı şu şekilde açıkça içe aktarın:

docker save myapp:0.1 | sudo k3s ctr images import -
sudo k3s crictl images

Ardından, o container üzerinde :latest etiketini kullanmaktan kaçının. Çünkü :latest, varsayılan olarak Always değerinde bir imagePullPolicy kullanır ve kubelet her durumda bir kayıt defterine (registry) yönelir. Diğer tüm etiketler, içe aktardığınız imajı kullanan IfNotPresent varsayılanına sahiptir. Her ikisini de tek bir VPS üzerinde çalıştırmak mümkündür; bu noktada bir VPS üzerinde standart Docker kurulumu ile k3s'in kendi imaj depolarını ve kendi iptables kurallarını aynı makine üzerinde ayrı ayrı yönettiklerini bilmek faydalıdır.

k3s nasıl kaldırılır

Yükleyici, bir kaldırma betiği oluşturur. Kısmi kaldırma veya geri alma işlemi desteklenmez.

sudo /usr/local/bin/k3s-uninstall.sh

Bu betik servisi durdurur ve kaldırır, veri deposunu siler, kalıcı birim (persistent volume) verilerini siler, düğüm yapılandırmasını kaldırır ve yükleyicinin eklediği araçları temizler. Bir aracı (agent) düğümünde betik bunun yerine k3s-agent-uninstall.sh komutudur. /var/lib/rancher/k3s/storage altındaki her şeyi öncelikle sunucudan başka bir yere kopyalayın, çünkü bu dizin işlemle birlikte silinecektir. İşlem sonrasında, ip link show ve sudo ss -lntp komutlarını kullanarak portları veya ağ arayüzlerini tutan herhangi bir öğe kalmadığından emin olun. Geride kalan bir cni0 veya flannel.1 arayüzü, bir sonraki yeniden başlatmada temizlenecektir.

Kubernetes düğümünün iş yükü için gereğinden fazla karmaşık olduğuna karar vermek, bir başarısızlık değil, olağan bir sonuçtur. Bu iş yüklerini tekrar Compose yapısına taşımak genellikle bir öğleden sonra sürecek bir işlemdir.

Hata modları ve karşılaşacağınız dizeler

Node NotReady durumu veya k3s'in döngüsel olarak yeniden başlaması. Öncelikle sudo journalctl -u k3s -n 200 --no-pager kısmını okuyun. Küçük bir VPS üzerinde yaygın görülen neden, çekirdeğin bellek yetersizliği (OOM killer) nedeniyle süreci sonlandırmasıdır; bu durum dmesg içerisinde k3s-server adını taşıyan bir satır olarak görünür. Belgelenen 2 GB minimum değer, gerçek bir alt sınırdır.

Pod'un Pending durumunda takılı kalması. kubectl describe pod her seferinde sorunu belirtir. Insufficient memory veya Insufficient cpu, düğümde yer kalmadığı anlamına gelir. didn't have free ports, yukarıda bahsedilen hostPort çakışmasıdır. Bir PVC üzerinde waiting for first consumer görülmesi, WaitForFirstConsumer özelliğinin görevini yaptığını gösterir.

ImagePullBackOff. Etiket, düğümün erişebildiği hiçbir kayıt defterinde mevcut değildir veya görüntüyü Docker ile oluşturup containerd içerisine aktarmamışsınızdır.

Traefik yanıt veriyor ancak uygulama vermiyor. 404 page not found yanıt gövdesi doğrudan Traefik'ten gelir ve isteğin ulaştığını ancak eşleşen bir yönlendirici (router) bulunamadığını belirtir. Ingress host değerinin yazdığınız isimle eşleştiğinden ve ingressClassName değerinin traefik olduğundan emin olun.

Küme DNS'i başarısız olurken ana makinenin çözümleme yapabilmesi. CoreDNS durumunu sudo k3s kubectl -n kube-system logs -l k8s-app=kube-dns ile kontrol edin. plugin/loop: Loop ... detected for zone "." gibi bir mesaj, CoreDNS'in başlamasını engeller. Bu durum, CoreDNS'in kendisine geri yönlendirme yapan bir çözümleyiciye istek göndermesinden kaynaklanır; /etc/resolv.conf içerisindeki bir loopback adresi buna neden olur. k3s'i --resolv-conf /run/systemd/resolve/resolv.conf kullanarak gerçek üst akış (upstream) dosyasına yönlendirin.

FAQ

k3s tek bir VPS üzerinde çalıştırmaya değer mi?

Kubernetes API'sine ihtiyaç duyduğunuzda buna değer: kontrolünüz altındaki bir makinede öğrenmek, dağıtımları manifest dosyaları olarak taşınabilir tutmak, yalnızca Helm chart yayınlayan yazılımları çalıştırmak veya daha sonra yönetilen bir kümeye taşıyacağınız bir yapı kurmak. Yalnızca konteyner çalıştırmak istiyorsanız buna değmez; çünkü Docker Compose bunu çok daha az bakım gereksinimiyle ve yaklaşık bir gigabayt daha fazla boş RAM ile yapar. Tek düğüm size yüksek erişilebilirlik sağlamaz, bu nedenle güvenilirlik onu seçmek için bir neden olamaz.

k3s LoadBalancer servisim neden Pending durumunda kalıyor?

ServiceLB, düğüm üzerindeki hostPort olarak servisin portlarını talep eden svclb- pod'larını oluşturur, bu nedenle yalnızca bu portların boş olduğu yerlerde zamanlama yapabilirler. Eğer nginx veya başka bir proxy zaten 80 numaralı portu kullanıyorsa, pod Pending durumunda kalır ve servis hiçbir zaman harici bir adres alamaz. kubectl -n kube-system describe pod svclb-..., 0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports hatasını bildirir. Portu serbest bırakın veya --disable=servicelb ile yeniden yükleyin ve servisin hala tahsis ettiği NodePort'a proxy yapın.

k3s bir VPS üzerinde ne kadar RAM'e ihtiyaç duyar?

Bir sunucu düğümü için belgelenen minimum değer 2 çekirdek ve 2 GB'tır; bu, iş yüklerinizden önce k3s ve paketlenmiş bileşenlerini kapsar. Projenin kendi profil oluşturma çalışmaları, üzerinde bir izleme yığını çalışan bir sunucu düğümünü 1,596 MB olarak ölçmüştür, bu yüzden 2 GB'ı taban, 4 GB'ı ise tek bir düğümün rahat çalıştığı ilk boyut olarak kabul edin. Kendi sunucunuzu, kurulumdan önce ve kube-system içindeki her pod Running durumuna geçtikten sonra free -h ile ölçün.

Aynı VPS üzerinde Docker ve k3s çalıştırabilir miyim?

Evet, ikisi birbirinden ayrı kalır. k3s kendi gömülü containerd'sini kullanır, bu nedenle docker build ile oluşturulan bir imaj, siz docker save myapp:0.1 | sudo k3s ctr images import - komutunu çalıştırana kadar k3s tarafından görülmez. Her biri ayrıca kendi iptables kurallarını ve kendi köprü ağlarını yazar. Toplam bellek kullanımını izleyin, çünkü Docker, k3s ve konteynerleriniz 2 GB'lık bir sunucuya sığmayacaktır.

k3s'i tamamen nasıl kaldırırım?

Bir sunucu düğümünde sudo /usr/local/bin/k3s-uninstall.sh veya bir aracı düğümünde sudo /usr/local/bin/k3s-agent-uninstall.sh komutunu çalıştırın. Bu komut servisi durdurur, veri deposunu siler, /var/lib/rancher/k3s/storage altındaki kalıcı birim verilerini siler ve paketlenmiş araçları kaldırır. Saklamak istediğiniz tüm verileri önceden sunucudan kopyalayın, çünkü bu işlemin geri dönüşü yoktur. Artık kalan bir cni0 veya flannel.1 ağ arayüzü bir sonraki yeniden başlatmada kaybolacaktır.