Talos Linux ile sıfırdan Kubernetes: kabuğu olmayan bir işletim sistemiyle çalışmak

Kubernetes kümesinin altındaki işletim sistemi, çoğu ekipte en az konuşulan ama en çok emek yiyen katmandır. Genel amaçlı bir dağıtım kurup üstüne kubeadm ile küme çıkarmak ilk gün kolaydır. İkinci yılda elinizde birbirinden hafifçe farklılaşmış on beş düğüm, kimin ne zaman ne kurduğu belli olmayan bir paket listesi ve "önce şu düğümü boşalt" diye başlayan yedi adımlık bir yükseltme prosedürü olur. Talos Linux bu katmanı tamamen kapatarak çözmeyi öneriyor: düğümde kabuk yok, SSH yok, paket yöneticisi yok, elle düzenlenecek dosya yok. Tek arayüz bir API.

Değişmez ve API ile yönetilen işletim sistemi ne demek

Talos'un kök dosya sistemi salt okunurdur ve düğümde genel amaçlı bir kullanıcı alanı bulunmaz. Sistem yalnızca Kubernetes düğümü olmak için gereken bileşenleri taşır: kubelet, containerd, kontrol düzlemi düğümlerinde etcd ve bunların hepsini yöneten Talos'un kendi süreç denetleyicisi. systemd yok, bash yok, apt ya da dnf yok.

Bunun günlük işleyişteki karşılığı şu: düğüme "girip bakmak" diye bir eylem kalmıyor. Yapılandırma değişikliği API'ye gönderilen bir belge, hata ayıklama ise API'den okunan bir kayıt akışı. Talos API varsayılan olarak 50000 numaralı portta dinler ve karşılıklı TLS ister; istemci sertifikanız yoksa düğümle hiç konuşamazsınız.

Kaybettiğiniz şey gerçek: bir düğümde tcpdump çalıştırıp trafiğe bakmak, strace ile takılan bir süreci kurcalamak, hızlıca bir dosyayı düzeltip servisi yeniden başlatmak. Kazandığınız şey de gerçek: yapılandırma sapması diye bir sorun sınıfı ortadan kalkar, çünkü sapmayı üretecek mekanizma yoktur. Bir düğüm ya belgede yazan hâldedir ya da bozuktur. Arada "geçen sene biri elle düzeltmişti" durumu oluşmaz, çünkü elle düzeltmenin yolu yoktur.

Machine config: tek belge, iki bölüm

Talos'ta bir düğümün tüm kişiliği tek bir YAML belgesinde durur ve belgenin iki üst bölümü vardır. machine düğüme ait olan her şeyi taşır: ağ, kurulum diski, kubelet ayarları, sertifikalar, yüklenecek çekirdek modülleri. cluster ise kümeye ait olanı: API sunucusu ayarları, etcd, ağ tanımları, ortak sırlar.

Belgeler talosctl gen config ile üretilir. Komut üç dosya çıkarır: kontrol düzlemi için bir yapılandırma, worker için bir yapılandırma ve sizin istemci kimliğinizi taşıyan talosconfig. Üçüncüsünü kaybetmek kümeye erişimi kaybetmek demektir; ilk günden bir sır kasasına konmalı, depoya değil.

version: v1alpha1
machine:
  type: controlplane
  install:
    disk: /dev/sda
    image: ghcr.io/siderolabs/installer:v1.9.0
  network:
    hostname: cp-1
    interfaces:
      - interface: eth0
        addresses:
          - 198.51.100.11/24
        routes:
          - network: 0.0.0.0/0
            gateway: 198.51.100.1
cluster:
  network:
    cni:
      name: none

Düğüm başına farklılaşan ayarları tam belgeyi kopyalayarak değil, yama olarak tutun. Yamayı önce çevrimdışı uygulayıp sonucu gözle görmek mümkün:

talosctl machineconfig patch controlplane.yaml \
  --patch @patches/cp-2.yaml -o cp-2.yaml

Ya da tek adımda gönderin:

talosctl apply-config --nodes 198.51.100.12 \
  --file controlplane.yaml --config-patch @patches/cp-2.yaml

Bu ayrım pratikte önemli bir alışkanlık doğuruyor: değişiklik artık "sunucuda bir dosyayı düzenledim" değil, sürüm kontrolünde duran ve gözden geçirilebilen bir yama.

Sıfırdan küme

Akış kısa. Düğümleri Talos imajıyla açarsınız; yapılandırılmamış düğüm bakım modunda gelir ve API'yi sertifika istemeden dinler. İlk yapılandırmayı bu yüzden --insecure ile gönderirsiniz.

talosctl gen config demo https://198.51.100.11:6443 \
  --install-disk /dev/sda --output-dir ./out

talosctl apply-config --insecure --nodes 198.51.100.11 \
  --file ./out/controlplane.yaml
talosctl apply-config --insecure --nodes 198.51.100.21 \
  --file ./out/worker.yaml

export TALOSCONFIG=./out/talosconfig
talosctl config endpoint 198.51.100.11
talosctl config node 198.51.100.11

talosctl bootstrap
talosctl kubeconfig .
talosctl health

bootstrap yalnızca bir kez ve yalnızca tek bir kontrol düzlemi düğümünde çalıştırılır. etcd'yi orada başlatır, diğer kontrol düzlemi düğümleri kümeye kendiliğinden katılır. Bunu ikinci bir düğümde de çalıştırmak iki ayrı etcd kümesi doğurur; toparlaması sıfırdan kurmaktan uzun sürer.

Yükseltme

İşletim sistemi yükseltmesi bir API çağrısıdır. Düğüme yeni bir installer imajı adresi verirsiniz, düğüm o imajı çeker, alternatif bölüme yazar ve yeniden başlar:

talosctl upgrade --nodes 198.51.100.11 \
  --image ghcr.io/siderolabs/installer:v1.9.0

Bölüm düzeni A/B olduğu için önceki çekirdek ve imaj yerinde kalır. Yeni sürüm açılamazsa sistem kendiliğinden eskisine döner. Elle geri almak için talosctl rollback var, ama tek bir adım geri gider: iki sürüm atladıysanız ikincisine dönemezsiniz, oraya gitmek için hedef sürümü upgrade ile açıkça vermeniz gerekir.

Kubernetes sürümü işletim sisteminden ayrı yükseltilir:

talosctl --nodes 198.51.100.11 upgrade-k8s --to 1.31.4 --dry-run

Komut kontrol düzlemi bileşenlerini ve kubelet'i doğru sırayla, her adımda sağlık bekleyerek yükseltir. --dry-run ile ne yapacağını önce görebilirsiniz. Bu ayrımın işletmedeki faydası büyük: işletim sistemi yamasıyla Kubernetes sürüm atlamasını aynı bakım penceresine sıkıştırmak zorunda kalmazsınız, ikisi bağımsız kararlardır.

Kabuk olmadan hata ayıklama

Alışması en çok zaman alan kısım burası. Refleksleriniz yenilenir:

talosctl -n 198.51.100.11 logs -f kubelet
talosctl -n 198.51.100.11 dmesg
talosctl -n 198.51.100.11 get members
talosctl -n 198.51.100.11 get staticpods
talosctl -n 198.51.100.11 dashboard
talosctl -n 198.51.100.11 support -O destek.zip

get komutu Talos'un iç kaynak modelini sorgular: adresler, arayüzler, servis durumları, üretilmiş statik pod tanımları. Düğümde neyin neden o hâlde olduğunu genellikle burada bulursunuz, çünkü kaynaklar yapılandırmadan türetilmiş sonuçlardır ve türetme zincirini geriye doğru okuyabilirsiniz. Ağ ya da çekirdek seviyesinde gerçekten derin bakış gerekiyorsa yol, ayrıcalıklı ve host ağını kullanan geçici bir hata ayıklama podu açmaktır. İşe yarar ama SSH kadar hızlı değildir; acil durumda bu podun manifestinin hazır durması iyi fikirdir.

kubeadm ile işletme yükü farkı

• İşletim sistemi yaması: klasik kurulumda güvenlik güncellemesi, yeniden başlatma koordinasyonu ve düğüm boşaltma ayrı ayrı yönetilir. Talos'ta tek bir API çağrısı, atomik imaj ve otomatik geri dönüş var.
• Sapma: yapılandırma yönetimi aracıyla yakınsama denemesi yerine, sapmanın üretilemediği bir model.
• Erişim denetimi: SSH anahtarı dağıtımı, sudo kuralları ve oturum denetimi yerine tek bir istemci sertifikası ve rol.
• Saldırı yüzeyi: konteynerden kaçan bir saldırganın çalıştıracağı kabuk ya da indirme aracı yok.
• Karşılığında ödenen bedel: sürücü ya da özel bir ajan eklemek istediğinizde imaj üretme sürecine girersiniz. Talos'ta paket kurulmaz, sistem uzantısı eklenir ve uzantıları içeren imaj bir şema tanımıyla üretilir. Bir kere kurulduktan sonra kolay, ama ilk seferinde alışılmadık.

Alışkanlıklar ve öğrenme eğrisi

Kubernetes'i bilen bir ekip için asıl eğri Talos'un kavramları değil, kaybedilen kaçış yolu. "Bir bakayım" diye düğüme bağlanma alışkanlığı yerine hipotezi önce yapılandırmada aramak gerekir. Bunun beklenmedik bir yan etkisi var: sorunlar daha çok belge ve daha az kişi bilgisi hâline gelir, çünkü kimsenin kendi kafasında tuttuğu "şu düğümde şöyle bir düzeltme vardı" bilgisi kalmaz.

İkinci alışkanlık değişimi yetki dünyasının ikiye ayrılması. kubectl ile yaptığınız iş ile talosctl ile yaptığınız iş farklı sertifikalarla, farklı rollerle yürür. Bir geliştiriciye küme erişimi vermek düğüm erişimi vermek anlamına gelmez, bu iyidir, ama nöbet prosedürlerinizde ikisini de düşünmeniz gerekir.

Tuzaklar

• Kurulum diskini yanlış seçmek. Birden fazla diski olan makinelerde /dev/sda sabiti değişebilir; disk seçicisini boyut ya da seri numarası üzerinden yazmak daha güvenli.
• Uzantıları unutmak. Sistem uzantıları imajın parçasıdır. Yükseltirken yeni sürümün imajını aynı uzantı şemasıyla üretmezseniz, sürücüleriniz yükseltmeden sonra yok olur.
• talosconfig ve gizli anahtarları depoya koymak. Bu dosyalar kümenin tamamına yetkilidir.
• Talos API portunu genel internete açmak. Karşılıklı TLS koruyor olsa da bu portun yönetim ağıyla sınırlandırılması gerekir.
• CNI beklentisi. Varsayılan yapılandırma kendi ağ eklentisini getirir; başka bir eklenti kuracaksanız bunu ilk günden kapatıp kendi kurulumunuzu yapın, sonradan değiştirmek daha zahmetli.
• Yedek kapsamı. Uygulama yedekleme aracınız Kubernetes nesnelerini alır, ama kontrol düzlemini geri getirecek olan etcd anlık görüntüsüdür; onu ayrıca ve düzenli almanız gerekir.

Ne zaman Talos seçmemeli

Makinede Kubernetes dışında bir şey çalışacaksa seçmeyin. Yanına bir veritabanı, bir yedekleme ajanı ya da eski bir servis koymanız gerekiyorsa Talos bunu size zorlaştırmak için tasarlanmıştır.

Uyumluluk gereksiniminiz düğümde konteyner olarak koşamayan bir ajan dayatıyorsa seçmeyin. Uzantı olarak paketlemek mümkün olabilir, ama satıcı desteğiniz bunu kapsamayabilir.

Ekip Kubernetes'i henüz iyi bilmiyorsa seçmeyin. Aynı anda iki bilinmeyenle uğraşmak, sorun çıktığında hangi katmanın suçlu olduğunu ayırt etmeyi zorlaştırır. Önce tanıdık bir dağıtımla küme işletip refleksleri oturtmak, sonra geçmek daha ucuz.

Tek düğümlük bir geliştirme ortamı istiyorsanız daha hafif seçenekler daha az sürtünme üretir. Ve yönetilen bir Kubernetes servisi işinizi görüyorsa, işletim sistemi katmanını hiç devralmamak zaten en az iş çıkaran seçenektir; Talos'un asıl kazandırdığı yer o katmanın sizde olduğu kurulumlardır.

Karar vermeden önce yapılabilecek en ucuz deneme şu: üç sanal makineyle bir küme kurun, bir düğümü bilerek yükseltip geri alın, sonra da kabuk olmadan gerçek bir sorunu teşhis etmeye çalışın. Yarım günde hem akışı hem de ekibin bu modelle ne kadar rahat olduğunu ölçmüş olursunuz.