Kubernetes'i bağlamak: cluster'da Tower, port açmadan

Bu sayfa bir Kubernetes cluster'ını Spitfire'a baştan sona bağlar: node'ların sunucu metrikleri (CPU, bellek, disk, ağ), kubelet metrikleri (pod ve container) ve cluster'ın durumu (Deployment, DaemonSet, node koşulları). Tower cluster'ın içinde çalışır ve Spitfire'a tek bir giden bağlantı açar: cluster'a dışarıdan hiçbir port açılmaz. Veri kaynağının alanları ve cluster görünümü: Altyapı izleme: Kubernetes.

#Ön koşullar

• Sürekli metrikler açık: Tower'lar ve metrikler Spitfire'da: /towers → Metrikleri topla ve sakla (Metrikleri açmak). Kapalıyken Tower metrikleri alır ama atar; manifest sorunsuz uygulanır, hiçbir şey görünmez.
• Bir Tower: bu sayfa onu cluster'ın içine kurar (Cluster'ın içinde Tower). Ağda zaten bir Tower varsa ve cluster'ın pod'ları ona ulaşabiliyorsa onu da kullanabilirsiniz.
• kubectl erişimi: namespace, ClusterRole ve ClusterRoleBinding oluşturabilen bir kullanıcı (genelde cluster-admin). Kubernetes 1.25 ve sonrası (Pod Security etiketleri).
• Giden bağlantı: Tower pod'u Spitfire'ın adresine (HTTPS) ulaşabilmeli. İnternet çıkışı başka hiçbir şey için gerekmez.
• Kurulum yöneticisi: Tower'lar sayfası yalnız kurulum yöneticisine açıktır.

#Neler kurulur

Hepsi spitfire namespace'inde; ClusterRole ve ClusterRoleBinding cluster genelindedir.

Pod Security: host Collector açıksa namespace enforce: privileged olur, çünkü node'un kökünü, ağını ve süreçlerini okumak (hostPath, hostNetwork, hostPID) başka hiçbir seviyede yoktur. warn ve audit restricted kalır; host Collector dışındaki her pod (Tower, kubelet ve cluster Collector'ları) restricted'a uyar: root olmayan kullanıcı, RuntimeDefault seccomp, salt okunur kök dosya sistemi, bütün capability'ler düşürülmüş. Host Collector kapalıysa namespace enforce: restricted olur.

#Cluster'ın içinde Tower

1. Tower'lar ve metrikler Spitfire'da: /towers → Tower ekle → ad (ör. prod-eu-k8s) ve isteğe bağlı bölge → Tower ekle.

2. İki token yalnız bu pencerede görünür. Pencereyi kapatmayın, sonraki adımları açıkken yapın.

3. Kubernetes (manifest) sekmesini seçin.

4. Her node'u bir sunucu olarak da izle kutusu: açıkken node'lar Sunucular'da görünür (namespace privileged olur, yukarıda). Mobil bildirimleri bu Tower taşıyacaksa ilgili kutuyu da işaretleyin.

5. 1. Namespace ve Secret'lar komutunu kopyalayıp cluster'a erişen bir terminale yapıştırın. İki kez token sorar: önce sftower_…'u, sonra sfcol_…'u pencereden kopyalayıp yapıştırın, her birinde Enter.

6. 2. spitfire-tower.yaml içeriğini ev klasörünüze spitfire-tower.yaml olarak kaydedin.

7. Uygulayın:

   bashKopyala

   kubectl apply --dry-run=server -f spitfire-tower.yaml && kubectl apply -f spitfire-tower.yaml

   --dry-run=server önce sunucuya sorar: Pod Security ya da yetki reddi burada, hiçbir şey değişmeden görünür.

8. Tower listede Bağlı olur (birkaç saniye). Sekmenin altındaki adres (http://spitfire-tower.spitfire.svc:4318) veri kaynağının Tower adresidir.

NetworkPolicy yalnız 4318'e izin verir. Host Collector kapalıyken yalnız spitfire namespace'indeki pod'lar gönderebilir. Açıkken host Collector node'un adresinden gönderdiği için (hiçbir pod seçicisi onu tutmaz) port cluster'a açıktır ve kapıyı sfcol_ token'ı korur. NetworkPolicy'yi uygulamayan bir CNI'de kural yok sayılır.

#Secret'lar gizli sorudan

Komut token'ları read -rs ile sorar: ekranda görünmezler, kabuk geçmişine ve manifest'e girmezler. kubectl'e standart girdiden (--from-file=…=/dev/stdin) verilirler; --from-literal değeri komut satırında bırakır, süreç listesinde ve geçmişte görünür. Komut tek mantıksal satırdır (satır sonları \): çok satırlı bir blok yapıştırılınca read bir sonraki yapıştırılan satırı token sanar. Elle yazmak isterseniz:

kubectl create namespace spitfire
printf 'sftower_ token: ' && read -rs SF_TOWER && echo && \
printf 'sfcol_ token: ' && read -rs SF_COL && echo && \
printf '%s' "$SF_TOWER" | kubectl -n spitfire create secret generic spitfire-tower --from-file=SPITFIRE_TOWER_TOKEN=/dev/stdin && \
printf '%s' "$SF_COL" | kubectl -n spitfire create secret generic spitfire-collector --from-file=token=/dev/stdin; \
unset SF_TOWER SF_COL

Manifest token taşımadığı için bir depoda (GitOps) tutulabilir; Secret'lar ayrı yönetilir.

#İmajı digest'e sabitlemek

Manifest imajı etiketle verir (usespitfire/spitfire:<sürüm> ve host Collector için <sürüm>-collector); sürüm Spitfire'ınkiyle aynı olmalıdır. Etiket yerine digest isterseniz:

docker buildx imagetools inspect usespitfire/spitfire:<sürüm> --format '{{json .Manifest.Digest}}'
docker buildx imagetools inspect usespitfire/spitfire:<sürüm>-collector --format '{{json .Manifest.Digest}}'

ve manifest'teki image: satırlarını usespitfire/spitfire:<sürüm>@sha256:<digest> yapın. Sürüm yükseltirken yeni manifest'i pencereden alıp kubectl diff -f spitfire-tower.yaml ile karşılaştırın.

#Kubernetes veri kaynağı

1. Altyapı izleme → Kaynak ekle → Kubernetes. Ön koşullardan biri eksikse pencere bunu en üstte söyler.

2. Manuel kurulum sekmesi: Cluster adı (ör. prod-eu; Spitfire'da cluster'ın adı olur) ve Tower adresi http://spitfire-tower.spitfire.svc:4318 → Kaydet.

3. Secret komutunu atlayın: spitfire-collector Secret'ı Tower adımında oluştu. (Ağdaki başka bir Tower'a gönderiyorsanız komutu çalıştırın; o Tower'ın sfcol_ token'ını sorar.)

4. Manifest komutunu Kopyala ile kopyalayıp aynı terminalde çalıştırın. Tek komuttur (kubectl apply -f - <<'EOF' … EOF); dosya kaydetmeniz gerekmez. Sonra rollout'u bekleyin:

   bashKopyala

   kubectl -n spitfire rollout status daemonset/spitfire-collector-node --timeout=120s

5. Test et: "Cluster içinden toplanıyor" ise bekleyin; ilk veri 1-2 dakikada gelir.

Hızlı kurulum sekmesi de aynı işi yapar: Komutu oluştur bir saatlik, tek kullanımlık sfsetup_ token'lı bir komut verir; betik kubectl context'ini, cluster adını, Tower adresini ve sfcol_ token'ını sorar, var olan Secret'ı günceller ve manifest'i uygular. Token yalnız düğmeye basınca üretilir; pencereyi açıp kapatmak geçerli bir token bırakmaz.

#Doğrulama

1. Pod'lar Running: bir spitfire-tower, her node'da bir spitfire-collector-node (ve host Collector açıksa bir spitfire-collector-host), bir spitfire-collector-cluster.

   bashKopyala

   kubectl -n spitfire get pods -o wide

2. Tower bağlandı: günlükte connected to controller var.

   bashKopyala

   kubectl -n spitfire logs deploy/spitfire-tower | grep -E 'connected|unreachable|not kept'

3. Collector günlüklerinde no such host, connection refused, forbidden ya da 401 yok:

   bashKopyala

   kubectl -n spitfire logs ds/spitfire-collector-node --tail=50
   kubectl -n spitfire logs deploy/spitfire-collector-cluster --tail=50

4. Spitfire'da: Tower'lar ve metrikler'de Tower Bağlı ve trafiği artıyor; Altyapı izleme'de Kubernetes kaynağı yeşil; APM → Kubernetes'te node'lar ve namespace'ler; host Collector açıksa Sunucular'da node adları.

#Sık hatalar

#Geri almak

1. Spitfire'da: Altyapı izleme'den Kubernetes kaynağını silin, Tower'lar ve metrikler'de Tower'ı İptal et. İki token geçersiz olur.

2. Cluster'da manifest'leri silin (ClusterRole, ClusterRoleBinding ve namespace dahil; Secret'lar namespace ile gider):

   bashKopyala

   kubectl delete namespace spitfire
   kubectl delete clusterrolebinding spitfire-collector --ignore-not-found
   kubectl delete clusterrole spitfire-collector --ignore-not-found

   Beklenen çıktı: namespace "spitfire" deleted, ardından ClusterRole ve ClusterRoleBinding için deleted. Başka bir namespace'e kurduysanız spitfire yerine onu yazın.

Geçmiş metrikler saklama süresi dolunca silinir.

#İlgili sayfalar

• Altyapı izleme: Kubernetes
• Tower ve sürekli metrikler
• Sunucu izleme
• APM