İçindekiler
- 1 Bir Akşamüstü Kesintisi ve 3 VPS’te K3s’e Giden Yol
- 2 Neden 3 VPS ve K3s? Ne Zaman Mantıklı?
- 3 Topoloji, IP Planı ve Hazırlık: Kümenin Gönül Rahatlığı
- 4 K3s Yüksek Erişilebilirlik: Üç Düğümle Sağlam Başlangıç
- 5 Traefik ile Giriş Trafiğini Tatlı Tatlı Yönetmek
- 6 cert‑manager ile Otomatik SSL: Unut, Yenilensin
- 7 Longhorn ile Kalıcı Depolama: Diske Güven, Omuzların Rahat
- 8 DNS, Giriş ve İlk Uygulama: “Merhaba” Demenin Tam Vakti
- 9 Güncellemeler, Yedekler ve Küçük Bakım Ritüelleri
- 10 Sorun Giderme: “Nereden Tutsam?” Dediğinizde
- 11 Kapanış: Üç Düğüm, Sakin Uykular
Bir Akşamüstü Kesintisi ve 3 VPS’te K3s’e Giden Yol
Hiç akşamüstü sakin bir anda, tek bir sunucuda koşan uygulamanızın bir anda sessizliğe gömüldüğünü gördünüz mü? Ben gördüm. Bir pazar akşamıydı, yavaş bir trafik, çayım dumanı üstünde… Derken bir mesaj: “Site açılmıyor.” Tek VPS, tek şans. Disk I/O zıplamış, servisler birbirine sıkışmış. O an tekrar anladım; konfor alanı, tek düğümde çalışırken hissedilen o tatlı rahatlık, en olmadık anda insanı ters köşe yapıyor.
İşte o akşam, “Bunu kalıcı olarak nasıl düzeltirim?” diye düşündüm. “Küçük, akıllı, kolay yönetilebilir bir küme… ama masrağı uçurmayacak ve kurması kabus olmayacak bir şey.” Derken yine aynı yere geldim: 3 VPS ve K3s. Basitlik seviyesi yüksek, ayakları yere basan bir yaklaşımla; önüne Traefik, sertifikayı cert‑manager, kalıcı depolamayı da Longhorn ile çözdüm. Bu yazıda o kurulumun, üretime hazır hale gelişinin hikâyesini anlatacağım. Hem de adım adım, “mesela şöyle düşünün” diye diye, gözünüzde büyütmeden.
Önce genel resmi çizeceğiz, sonra hazırlanacağız, ardından K3s HA kümesini kuracağız. Traefik’le trafiği yönetip cert‑manager ile SSL’leri otomatiğe bağlayacağız. Longhorn’la da veriyi güvene alacağız. En sonda da ufak bir uygulama yayımlayıp, “Tamam, bu iş oldu” diyeceğiz. Hazırsanız başlayalım.
Neden 3 VPS ve K3s? Ne Zaman Mantıklı?
Üç düğümün büyüsü, karar alabilmesi. Yani çoğunluk. Bir düğüm giderse, diğer ikisi “tamam, biz buradayız” diyerek kümeyi çalışır tutuyor. Bu, tek başınıza bir dağa çıkmak yerine küçük ama uyumlu bir ekiple yürümek gibi. K3s de bu yürüyüşte hafif bir sırt çantası. Klasik Kubernetes’in büyük orkestrası yerine, daha sade ama uyumlu bir topluluk gibi düşünebilirsiniz. Yeterince güçlü, ama elinizin altında.
Ne zaman mantıklı? Trafiğiniz çok uçuk değilse, tek düğümün sınırlarında sürekli çizgiyi zorlamıyorsanız ve “Uygulamam bir şey olursa ayakta kalmaya devam etsin” diyorsanız, tam zamanı. 3 VPS kurulumunda maliyetler görece makul kalır, yönetilebilirlik bozulmaz, işler rayında ilerler. Özellikle küçük SaaS’ler, ajans içi projeler, yan uygulamalar ve MVP’ler için birebir.
Ben genelde şöyle hayal ediyorum: Üç küçük apartman dairesi. Birinde mutfak, öbüründe salon, bir diğerinde yatak odası. Bir daireye bir şey olursa, diğerlerinde hayat akmaya devam eder. K3s de bunun teknik karşılığı gibi; küçük ama akıllı bir dağılım.
Topoloji, IP Planı ve Hazırlık: Kümenin Gönül Rahatlığı
Üç Düğüm, Net İsimler
Önce kafamızda netleştirelim: üç VPS’imiz var, adları ve IP’leri belli. Örneğin vps‑1, vps‑2, vps‑3. Hepsine aynı işletim sistemi (Ubuntu 22.04 veya 24.04 gayet iyi), aynı temel ayarlar, aynı güvenlik politikaları. SSH anahtarları yüklü, güncellemeler yapılmış, saat senkron, swap tercihi net. Hostname’ler kısa ve anlamlı; DNS kayıtları düzgün.
Güvenlik İçin Küçük Ama Kıymetli Dokunuşlar
Kapıları açık bırakmak hoş değil. Güvenlik duvarını mantıklı kurallarla kapatmak, sadece işimiz olan portları açmak, basit parola yerine anahtar kullanmak, bazen en kritik farkı yaratır. Eğer nereden başlayacağım derseniz, VPS sunucularını güvenli tutmak için pratik ipuçlarını bir kahve molasında gözden geçirmek iyi gelir.
Ön Koşulların İncelikleri
İşe bazı ufak ama önemli paketleri kurarak başlayabilirsiniz. Longhorn için iSCSI istemcisi ve NFS araçları gerekebilir. Sunucularda şu kurulumlar elinizi rahatlatır:
sudo apt-get update
sudo apt-get install -y open-iscsi nfs-common jq curl
Ağda 80 ve 443 portlarına gelen trafiğin her düğümden Traefik’e ulaşabildiğinden emin olun. İç ağda ise kube bileşenlerinin konuşacağı 6443 gibi portlar açık olmalı. Detaylara boğulmayacağız; temel prensip şu: uygulamanızın dışarıdan eriştiği portlar sade ve belirgin olsun, içeride ise düğümler birbirini rahatça görsün.
K3s Yüksek Erişilebilirlik: Üç Düğümle Sağlam Başlangıç
Küme Kurulumu Mantığı
K3s, yerleşik bir hafif veritabanı yerine artık gömülü etcd ile HA (yüksek erişilebilirlik) kurmaya izin veriyor. İlk düğüm kümenin çekirdeğini başlatıyor, diğer iki düğüm ona katılıyor. Tek bir ortak belirteç (token) kullanıyorsunuz. Mantık basit: ilk düğümü “cluster‑init” ile ayağa kaldır, kalanları “server” modunda bağla.
K3s Konfigürasyonu (config.yaml)
Düğümlerde K3s için aynı dosya yoluyla temel ayarları saklayacağız: /etc/rancher/k3s/config.yaml. İlk düğümdeki örnek ayar şöyle olabilir:
sudo mkdir -p /etc/rancher/k3s
sudo tee /etc/rancher/k3s/config.yaml >/dev/null <<'YAML'
write-kubeconfig-mode: '644'
node-name: 'vps-1'
node-ip: 10.0.0.11
node-external-ip: 203.0.113.11
disable:
- traefik
kube-apiserver-arg:
- 'service-node-port-range=80-32767'
YAML
Diğer düğümlerde node‑name, node‑ip ve node‑external‑ip değerlerini o düğümlere göre değiştirin. Traefik’i birazdan Helm ile kendimiz kuracağımız için burada devre dışı bıraktık.
İlk Düğümü Başlatma (cluster-init)
İlk düğümde bir belirteç seçin. Çok gizli tutun; diğer düğümler buna ihtiyaç duyacak.
export K3S_TOKEN='uzun-ve-gizli-bir-sey'
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC='server --cluster-init' sh -
Birkaç dakika bekleyin. K3s sunucu ayağa kalkınca kubeconfig dosyası /etc/rancher/k3s/k3s.yaml altında hazır olur. Kendi bilgisayarınıza kopyalayıp kubectl ile bağlanabilirsiniz.
Diğer İki Düğümü Küreye Katma
Bu sefer “server” modunda, ilk düğüme işaret ederek bağlanıyoruz. K3S_URL olarak ilk düğümün API adresini verin:
export K3S_TOKEN='uzun-ve-gizli-bir-sey'
export K3S_URL='https://203.0.113.11:6443'
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC='server' sh -
Aynı işlemi üçüncü düğümde de yapın. Birkaç dakika sonra düğümler birbirini görmeye başlar. Durumu kontrol etmek için:
sudo k3s kubectl get nodes -o wide
Eğer kendi bilgisayarınızdan bağlanacaksanız, ilk düğümdeki kubeconfig dosyasını ~/.kube/config içine kopyalayıp sunucu IP’lerini dış IP’lerle güncelleyin. Sonra “kubectl get nodes” dediğinizde üç düğümü görmeniz gerekir.
Traefik ile Giriş Trafiğini Tatlı Tatlı Yönetmek
Neden Helm ile Kuruyoruz?
K3s, Traefik’i varsayılan olarak getirebilir ama biz ayarları tam kontrol etmek istiyoruz. VPS ortamında bir bulut yük dengeleyici olmadığı için Traefik’i DaemonSet olarak, her düğümde 80 ve 443 portlarını dinleyecek şekilde hostPort ile kuracağız. Böylece hangi düğüme isabet ederse etsin, istek içeri girer.
Traefik Kurulumu
Önce bir values dosyası oluşturalım. Bu dosyada DaemonSet modunu ve hostPort’ları açacağız:
cat > traefik-values.yaml <<'YAML'
deployment:
kind: DaemonSet
ports:
web:
port: 80
hostPort: 80
websecure:
port: 443
hostPort: 443
ingressClass:
enabled: true
isDefaultClass: true
logs:
general:
level: INFO
access:
enabled: true
YAML
Traefik’i kuruyoruz:
helm repo add traefik https://traefik.github.io/charts
helm repo update
helm upgrade --install traefik traefik/traefik
--namespace kube-system
--create-namespace
-f traefik-values.yaml
Traefik hazır olunca, standart Ingress kaynaklarını kullanabiliriz. Daha meraklısı için Traefik’in Kubernetes Ingress belgeleri sade ve anlaşılır.
cert‑manager ile Otomatik SSL: Unut, Yenilensin
Kurulum ve ClusterIssuer
Sertifikaları elle almak, sonra yenilemeyi hatırlamak, prod ortamda sürpriz yaşatır. cert‑manager bu işi tertemiz çözüyor. Helm ile CRD’leri de kurarak başlıyoruz:
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm upgrade --install cert-manager jetstack/cert-manager
--namespace cert-manager
--create-namespace
--set installCRDs=true
Ardından üretim ve test (staging) için iki tane ClusterIssuer tanımlayalım. HTTP‑01 kullanacağız, çünkü Traefik 80 portunu dinliyor:
cat > cluster-issuers.yaml <<'YAML'
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-staging
spec:
acme:
email: [email protected]
server: 'https://acme-staging-v02.api.letsencrypt.org/directory'
privateKeySecretRef:
name: letsencrypt-staging-key
solvers:
- http01:
ingress:
class: traefik
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
email: [email protected]
server: 'https://acme-v02.api.letsencrypt.org/directory'
privateKeySecretRef:
name: letsencrypt-prod-key
solvers:
- http01:
ingress:
class: traefik
YAML
kubectl apply -f cluster-issuers.yaml
DNS tarafı da ayarlıysa, kısa süre içinde sertifikalar otomatik gelecektir. Eğer daha karmaşık bir yapıda, CA yedeklemesi yapmak isterseniz, ACME otomasyonunda yedekli CA kurarak oran limitlerine karşı dayanıklılık güzel bir rehber niteliğinde. Ayrıca anlatım ve örnekler için cert‑manager belgeleri elinizin altında bulunsun.
Longhorn ile Kalıcı Depolama: Diske Güven, Omuzların Rahat
Neden Longhorn?
Uygulamalarınız veriyi dosyaya yazdığında, Pod yeniden başlasa bile o veri bir yerde sağlam dursun istersiniz. Longhorn, tam bu işi kolaylaştırıyor. Düğümler arasında replike ederek bir disk sorununun tüm uygulamayı düşürmesini engelliyor. Küçük kümelerde kurulumu ve yönetimi şaşırtıcı derecede rahat.
Kurulum
Ön koşul paketlerini kurduğunuzu varsayalım. Helm ile Longhorn’u kuralım:
helm repo add longhorn https://charts.longhorn.io
helm repo update
helm upgrade --install longhorn longhorn/longhorn
--namespace longhorn-system
--create-namespace
Kurulum tamamlanınca, longhorn-system içinde Pod’lar “Running” olana kadar bekleyin. Varsayılan StorageClass olarak Longhorn’u işaretlemek isteyebilirsiniz. Çoğu zaman otomatik gelir; gelmezse bir göz atın:
kubectl get storageclass
# Gerekirse:
# kubectl patch storageclass longhorn -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'
Yedeklemeler için S3 uyumlu bir hedef belirleme, disk alarm eşikleri ve replikasyon sayısı gibi ayarları UI üzerinden ya da manifestlerle yapabilirsiniz. Merak ettiğiniz ayrıntılar için Longhorn dokümantasyonu açık ve anlaşılır.
DNS, Giriş ve İlk Uygulama: “Merhaba” Demenin Tam Vakti
DNS’i Nasıl Basit Tutmalı?
VPS ortamında genelde bir yük dengeleyiciniz yok. Traefik’i her düğümde 80/443’te dinleyen DaemonSet olarak kurduğumuz için, alan adınızı üç IP’ye de işaret edebilirsiniz. İstek hangi düğüme düşerse düşsün, kümenin içerisine alınır. DNS tarafında dayanıklılığı artırmak isterseniz, çoklu sağlayıcı DNS ile kesintisiz isim çözümleme güzel fikirler verir.
Basit Bir Uygulama ve Ingress
Hadi ufak bir “whoami” uygulaması atalım. Bir Deployment, bir Service, bir de Ingress ile başlayalım. Ingress’te cert‑manager’ı devreye sokacağız:
cat > app.yaml <<'YAML'
apiVersion: apps/v1
kind: Deployment
metadata:
name: whoami
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: whoami
template:
metadata:
labels:
app: whoami
spec:
containers:
- name: whoami
image: containous/whoami:v1.5.0
ports:
- containerPort: 80
volumeMounts:
- name: data
mountPath: /data
volumes:
- name: data
persistentVolumeClaim:
claimName: whoami-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: whoami-pvc
namespace: default
spec:
accessModes: ['ReadWriteOnce']
resources:
requests:
storage: 1Gi
storageClassName: longhorn
---
apiVersion: v1
kind: Service
metadata:
name: whoami
namespace: default
spec:
selector:
app: whoami
ports:
- name: http
port: 80
targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: whoami
namespace: default
annotations:
cert-manager.io/cluster-issuer: 'letsencrypt-prod'
spec:
ingressClassName: traefik
tls:
- hosts:
- app.example.com
secretName: whoami-tls
rules:
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: whoami
port:
number: 80
YAML
kubectl apply -f app.yaml
DNS’inizde app.example.com’u üç VPS IP’sine işaret ettiyseniz, kısa süre içinde TLS sertifikası oluşur ve uygulama HTTPS ile yanıt vermeye başlar. İlk “200 OK” mesajı ekranda belirdiğinde, o pazar akşamüstü stresini toprağa gömmüş olacaksınız.
Güncellemeler, Yedekler ve Küçük Bakım Ritüelleri
K3s’i Güncellemek
K3s’i güncellemek, bazen sadece kurulum komutunu yeniden çalıştırmak kadar basit olur. Düğümleri teker teker güncelleyin. Önce uygulamaların güvenle başka düğümlere kaymasını sağlamak için düğümü drain edin; sonra K3s’i güncelleyip geri alın.
kubectl drain vps-1 --ignore-daemonsets --delete-emptydir-data
curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL='stable' sh -
kubectl uncordon vps-1
Aynı ritmi diğer düğümler için de uygulayın. Küme ayakta kalır, trafik akmaya devam eder.
etcd Anlık Görüntüler (Snapshot)
K3s’in gömülü etcd’si için anlık yedek almak iyi bir alışkanlıktır. Elle tetiklemek isterseniz:
sudo k3s etcd-snapshot save --name manuelsnap-$(date +%Y%m%d-%H%M)
Otomatikleştirmek isterseniz K3s servis parametrelerine periyodik snapshot ayarı ekleyebilirsiniz. Dışarıya kopyalamayı da unutmayın; tek makinede kalan yedeğin faydası sınırlı olur.
Longhorn Yedekleri
Longhorn, yedeklemeleri S3 uyumlu bir depoya aktarabiliyor. Bir kez yapılandırınca, kritik PVC’leriniz için periyodik snapshot ve yedek planları tanımlayın. Ani bir hata anında geri dönüşünüzün süresi dakikalara iner, stres seviyesi de otomatik düşer.
Giriş Trafiği ve Sertifika Yenileme
Traefik’in erişim loglarını gerektiğinde açıp kapamak, sorun anında işinizi kolaylaştırır. cert‑manager sertifikaları otomatik yeniler; uzatma tarihlerini kontrol etmek için Secret’ların üzerindeki tarihlere bakabilirsiniz. Daha derin kurgu isteyen senaryolarda, DNS doğrulaması ve çok kiracılı alan adı yönetimini de düşünürsünüz; bu konuda çok kiracılı mimaride otomatik SSL ve DNS‑01 yaklaşımı güzel pratikler içeriyor.
Sorun Giderme: “Nereden Tutsam?” Dediğinizde
DNS mi, Ingress mi, Sertifika mı?
İlk önce en basitinden başlayın. Alan adınız doğru IP’lere çözülüyor mu? 80 portu açık ve Traefik’e ulaşıyor mu? Bu ikisi sağlamsa, Ingress kurallarınıza bakın; host adı doğru mu, path doğru mu? Sertifika için events çıktılarını kontrol edin; genelde eksik veya hatalı bir DNS kaydı tüm deliği gösterir.
Pod’lar Niye Dönmüyor?
Pod’lar CrashLoop’a düşüyorsa, çoğu zaman uygulama hatası, yanlış çevre değişkeni ya da ulaşılamayan bir dış kaynak vardır. “kubectl logs” ile başlayın, sonra “kubectl describe pod …” ile olayları okuyun. PVC’ler bağlanmıyorsa, Longhorn tarafına göz atın; disk alanı, replikasyon ve node taint’leri gibi küçük detaylar bazen büyük etkiler yapar.
Traefik Kuralı Çalışmıyor
IngressClass’ın “traefik” olduğundan emin olun. Yanlış sınıf, sanki kapıyı yanlış kapı ziliyle çalmaya benzer. Bir de 80/443 hostPort’ları her düğümde tek bir servis tarafından alınabilir; başka bir servis aynı portu kapmışsa çatışma olur. Kafayı karıştıran anlarda, Traefik’in Kubernetes Ingress belgeleri tekrar tekrar hayat kurtarır.
Kapanış: Üç Düğüm, Sakin Uykular
Üç VPS ile kurduğumuz K3s kümesi, Traefik’in girişte trafiği usulca yönettiği, cert‑manager’ın sertifikaları kendi kendine yenilediği, Longhorn’un veriyi güvenle tuttuğu küçük bir ekosistem. Sade, anlaşılır ve büyütülebilir. Bir pazar akşamı gelen “Site açılmıyor” mesajlarının tedirginliğini arka cebinize koyup, “Tamam, toparlar” diyebileceğiniz bir düzen bu. Kümenin ritmini bir kez kurduğunuzda, her gün biraz daha iyi hale getirirsiniz.
Pratik bir tavsiye: değişiklikleri küçük parçalara bölün. Önce küme, sonra Traefik, ardından cert‑manager, en sonda Longhorn. Her adımda kısa bir doğrulama yapın. DNS ayarlarınızı temiz tutun, logları gerektiğinde açıp kapayın, yedeklemeleri otomatiğe bağlayın. Bir de kendinize küçük bir kontrol listesi çıkarın; bakım zamanlarında “Neyi atladım?” diye düşünmek yerine ona bakarsınız. İsterseniz ACME tarafını daha da sağlamlaştırmak için, oran limitlerini ve yedek CA’yı planlayın; ismi bile rahatlatıyor.
Umarım bu rehber, üç küçük VPS’i güçlü bir ekibe dönüştürmenize yardımcı olur. Akılda takılan bir şey olursa not alın; bir sonraki yazıda belki onu konuşuruz. Bu arada DNS ve TLS tarafını güçlendirmek için önerdiğim içeriği de kenara kaydedin; bir gün mutlaka işinize yarayacak. Şimdilik bu kadar. Bir dahaki yazıda görüşmek üzere…
