Rook-Ceph ile Multus otomatik discovery nasıl çalışır?

· Levent Güneş · 3 dk okuma · Rook , Ceph , Multus , Kubernetes , Ağ

Selamlar, bu yazımda Rook-Ceph kurarken kafa karıştıran bir noktaya, Multus ile network CIDR keşfine bakacağız. Eğer cluster'ınızda Ceph trafiğini ayrı bir fiziksel arayüze taşımak istiyorsanız Multus zaten gündeminize girmiştir. Lafı uzatmadan başlayayım.

İşin özü şu: Ceph daemon'ları (mon, OSD, mgr) ayağa kalkarken hangi network'lerde dinleyeceklerini bilmek zorunda. Bu yüzden Ceph'in public_network ve cluster_network ayarlarına CIDR vermemiz gerekiyor. Pod ağında her şey statik IP olsa kolaydı, ama Multus devreye girince hikaye değişiyor.

Multus burada ne is yapiyor?

Kubernetes'te varsayılan olarak bir pod tek bir network interface ile gelir. Multus, pod'a ek interface'ler takmanızı sağlayan bir CNI meta-plugin. Ceph gibi storage backend'lerde bunu sevmemizin sebebi açık: client trafiği ile replikasyon trafiğini fiziksel olarak ayırmak istiyoruz. Replikasyon koştuğunda kullanıcı IO'sunun aynı NIC'te boğulmasını kim ister?

Rook tarafında siz NetworkAttachmentDefinition (NAD) tanımlıyorsunuz, sonra CephCluster spec'i içindeki network.selectors alanında onlara referans veriyorsunuz. Buraya kadar tamam.

Peki Rook, Ceph'e hangi CIDR'i vereceğini nereden biliyor? İşte burada iki yol var: otomatik keşif ve elle belirtilen addressRanges.

Otomatik kesif: canary pod'lari

Rook, addressRanges boş bırakıldığında geçici canary pod'lar ayağa kaldırır. Bu pod'lar hedef NAD'lere bağlanır, atanan IP'lerini k8s.v1.cni.cncf.io/network-status annotation'ından okur ve Rook bu bilgiyi Ceph konfigürasyonuna basar. Yani siz hiç CIDR yazmıyorsunuz, Rook kendi soruyor, kendi öğreniyor.

Minimal bir örnek şöyle:

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  network:
    provider: multus
    selectors:
      public: rook-ceph/rook-public-network
      cluster: rook-ceph/rook-cluster-network

addressRanges yok. Rook kalkıp gerekeni hallediyor. Şahsi kanaatim, IPAM kurulumunuz tek subnet üzerinde sade çalışıyorsa bu en az kafa şişiren yol.

Elle CIDR vermek: addressRanges

Otomatik keşif her zaman güllük gülistanlık değil. Heterojen node'larınız varsa, ya da IPAM tarafında deterministik bir konfigürasyon istiyorsanız addressRanges ile elle yazmak daha sağlıklı:

spec:
  network:
    provider: multus
    selectors:
      public: rook-ceph/rook-public-network
      cluster: rook-ceph/rook-cluster-network
    addressRanges:
      public:
      - 10.10.0.0/16
      cluster:
      - 10.20.0.0/16

Burada dikkat: selectors hâlâ zorunlu, sadece keşif adımını atlatıyorsunuz. Birden fazla subnet de listelenebilir; Ceph virgülle ayrılmış liste olarak görür ve eşleşen interface'e bind olur.

Dogrulama: gercekten dogru NIC'te mi?

İlk denememde monitor'ların pod ağı IP'sini kullandığını fark etmiştim, çünkü canary pod NAD'i alamamış ve Rook fallback yapmıştı. O yüzden uygulamadan sonra mutlaka kontrol edin:

kubectl -n rook-ceph logs -l app=rook-ceph-operator | grep -i 'network\|discover'

Bir de Ceph tarafında monitor adreslerinin storage network'te olduğunu teyit edin:

kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- ceph mon dump | grep 'mon\.'

Eğer mon.a hâlâ 10.244.x.x (yani CNI pod ağı) gösteriyorsa, otomatik keşif sizin istediğiniz interface'i seçmemiş demektir. addressRanges'e dönmeden önce node'ların gerçekten doğru subnet'te IP aldığını gözden geçirin.

Sik karsilasilan tuzaklar

  • NAD namespace'i atlamak: selectors altındaki referans <namespace>/<nad-adi> formatında olmalı. Sadece <nad-adi> yazarsanız Multus farklı namespace'te arar ve canary pod hata yer.
  • IPAM havuzunu kucuk tutmak: Canary pod'lar geçici olsa da IPAM'den IP çeker. Havuz daralmışsa OSD'ler ayağa kalkarken IP bulamaz, cluster yarı yarıya gelir.
  • MTU uyumsuzlugu: Storage network 9000 MTU iken NAD'de bunu unutmak klasik. Replikasyon paketleri parçalanır, performans yerlerde sürünür.
  • addressRanges'i selectors'siz yazmak: Olmaz. provider: multus dediğiniz an Rook'un selector'lara ihtiyacı var; addressRanges sadece Ceph'e geçecek CIDR'i belirler.

Kapanis

Bence burada karar şu kadar basit: tek subnet ve düzgün IPAM varsa otomatik keşfe güvenin, az iş çıkar. Heterojen ortamda ya da production'da deterministik davranış istiyorsanız addressRanges daha az süpriz çıkarır. Her iki durumda da ceph mon dump çıktısına bakmadan 'kuruldu' demeyin. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.