AWS'te Talos Linux için Hazır AMI'leri Kullanmak

· Esra Yalçın · 4 dk okuma · AWS , Talos Linux , Kubernetes

Selamlar, bu yazımda AWS üzerinde Talos Linux ile küme kurmaya niyetlenenler için bir kestirme yoldan bahsedeceğim: Sidero Labs'in resmi olarak yayınladığı hazır AMI'ler. Kendi image'ınızı Packer ile pişirmeye, bir image pipeline'ı sürdürmeye, her sürümde yeniden build almaya gerek yok. Doğru AMI'yi bulup user-data ile makine konfigürasyonunu geçiyorsunuz, gerisi Talos'un işi. Lafı uzatmadan başlayalım.

Talos AMI'leri kim yayınlıyor?

Sidero Labs, her Talos sürümü için tüm AWS bölgelerinde hem amd64 hem arm64 mimarileri için AMI yayınlıyor. Bu image'lar herkese açık ama AWS Marketplace'in tipik vitrininde değiller (orada da bir kayıt var, ama doğrudan değil); resmi yol ya Talos dokümantasyonuna bakmak ya da AWS CLI ile sorgulamak.

AMI'lerin sahibi (owner ID) 540036508848. Bu Sidero Labs'in AWS hesabı ve filtrelerken bu ID'ye dayanmak başka bir 'talos' isimli image'a yanlışlıkla denk gelmemenizi sağlıyor. Bence AMI seçerken her zaman --owners ile bu ID'yi vermek iyi bir alışkanlık; isim eşlemesine güvenmek bir gün sizi yanıltır.

Doğru AMI'yi bulmak

Bölgenizdeki son birkaç sürümü görmek için en hızlı yol şu:

# Bölgenizdeki son Talos AMI'lerini listele
aws ec2 describe-images \
  --owners 540036508848 \
  --filters 'Name=name,Values=talos-v1.7*' \
  --region us-east-1 \
  --query 'Images | sort_by(@, &CreationDate) | [-5:].{Name:Name, ImageId:ImageId, Arch:Architecture, Date:CreationDate}' \
  --output table

Çıktı son beş image'ı tarih sırasıyla verir; en alttaki en yenisidir. Aynı işi talosctl ile de yapabilirsiniz:

# Belirli sürüm ve mimari için varsayılan AMI'yi sor
talosctl image default --talos-version v1.7.0 --platform aws --arch amd64

İkisinin de pratik faydası farklı: CLI sorgusu hangi sürümlerin canlı olduğunu görmek için, talosctl ise script'lerden tek bir AMI ID çekmek için daha uygun.

Hangi varyant?

Talos'un AWS image'ları tek tip değil. En sık karşılaşacağınız üç varyant şöyle:

  • Standart: Çoğu donanım için derlenmiş kernel modülleriyle gelen varsayılan image. Tipik bir Kubernetes kümesi için bu yeter.
  • NVIDIA GPU: p3, p4, g4 ailesi GPU instance'lar için NVIDIA sürücüleri içerir. ML iş yükü çalıştıracaksanız buna geçin.
  • ZFS: Storage katmanınız ZFS gerektiriyorsa kernel modüllerini hazır getirir.

Standart image'ın işi görmediği özel bir senaryo yoksa onu seçin. Şahsi kanaatim, ihtiyaç doğmadan GPU veya ZFS varyantına atlamak gereksiz bagaj taşımak.

Instance'ları başlatmak

AMI ID'yi aldıktan sonra önce konfigürasyonu üretiyoruz:

# Talos konfigurasyonunu olustur
talosctl gen config my-cluster https://my-cluster-lb.us-east-1.elb.amazonaws.com:6443

# Bu komut su dosyalari uretir:
# - controlplane.yaml (control plane node'lar icin)
# - worker.yaml (worker node'lar icin)
# - talosconfig (talosctl kimlik dogrulamasi icin)

Sonra control plane'i kaldırıyoruz:

# Ilk control plane node'u baslat
aws ec2 run-instances \
  --image-id ami-0xxxxxxxxxxxxxxxxx \
  --instance-type m5.xlarge \
  --count 1 \
  --subnet-id subnet-xxxxxxxx \
  --security-group-ids sg-xxxxxxxx \
  --iam-instance-profile Name=talos-controlplane \
  --user-data file://controlplane.yaml \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=cp-1},{Key=kubernetes.io/cluster/my-cluster,Value=owned}]' \
  --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"VolumeSize":50,"VolumeType":"gp3","Encrypted":true}}]'

Buradaki kritik nokta --user-data ile controlplane.yaml'ı geçiriyor olmamız. Talos açıldığında maintenance mode'a girer ve user-data'da konfigürasyon görürse otomatik uygular; siz ayrıca SSH'lamak zorunda değilsiniz, zaten Talos'ta SSH yok.

Worker'ları da benzer şekilde, worker.yaml ile başlatın. Disk boyutu için control plane'de 50 GB rahat yeter; worker'da container image cache'i ve ephemeral storage'ı baz alıp 100-200 GB civarı bir yerde tutuyorum genelde.

Cluster'ı bootstrap etmek

Instance'lar ayağa kalkınca etcd'yi başlatmak için tek bir komut yetiyor:

# talosctl'i kumeye yonlendir
export TALOSCONFIG=./talosconfig
talosctl config endpoint <ControlPlaneIp>
talosctl config node <ControlPlaneIp>

# Ilk control plane node'unda etcd'yi bootstrap et
talosctl bootstrap

# Kume ayaga kalksin, kubeconfig'i al
talosctl kubeconfig ./kubeconfig
export KUBECONFIG=./kubeconfig
kubectl get nodes

Bu noktadan sonra elinizde çalışan bir Kubernetes kümesi var.

Sık karşılaşılan tuzaklar

  • Owner ID vermeden filtreleme: İsim filtresi tek başına başka birinin yayınladığı image'a denk gelebilir. Her zaman --owners 540036508848 kullanın.
  • EBS şifrelemesini unutmak: gp3'te şifreleme bedava, performans düşürmüyor; varsayılan olarak Encrypted: true verin. Sonradan dönüp düzeltmek snapshot dansı gerektirir.
  • Yanlış mimari AMI'si seçmek: arm64 image'ı x86 instance'a (ya da tersi) verirseniz boot'ta sessizce takılır. Sürüm filtresine Name=architecture,Values=arm64 eklemek hayat kurtarır.
  • Yeni node için launch template'i güncellememek: In-place upgrade çalışan node'lar için tatlı, ama yeni katılan node hâlâ eski AMI ile geliyorsa cluster'da sürüm karışıklığı olur. AMI'yi değiştirdiğinizde launch template'i de değiştirin.

Sürüm güncellemesi

Yeni bir Talos sürümü çıktığında her şeyi yeniden kurmanıza gerek yok, in-place upgrade var:

# Bir node'u yeni surume yukselt
talosctl upgrade --nodes <NodeIp> \
  --image ghcr.io/siderolabs/installer:v1.7.1

Doğru ayarlanmış pod disruption budget'larıyla iş yükleriniz drain edilip yeniden zamanlanır. Yine de yeni katılacak node'lar için launch template'i yeni AMI'ye işaret edecek biçimde güncellemeyi ihmal etmeyin.

Kapanış

Hazır AMI'ler, AWS üzerinde Talos ile küme kurmayı 'birkaç komut' işine indiriyor; image pipeline derdiniz olmuyor, her bölgede her sürüm hazır. Bence yola çıkarken standart image'la başlayın, Image Factory'ye ancak gerçek bir ihtiyaç doğduğunda uzanın. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.