Ekibiniz diğer her şeyi zaten Kubernetes'e dağıtıyorsa, bir MQTT broker'ı da Kubernetes üzerinde çalıştırmak doğal bir fikirdir. Bu yazı bu yolu efor, güncellemeler, güvenilirlik ve maliyet kalemleri açısından yönetilen bir hizmetle karşılaştırıyor ve denemeniz için çalışan bir manifest sunuyor. Sonunda Kubernetes'in bir broker için neyi çözdüğünü, neyi çözmediğini ve ekibinize hangi seçeneğin uyduğunu bileceksiniz.
Ekipler MQTT İçin Neden Kubernetes'i Düşünür?
Kubernetes size bildirimsel dağıtımlar, kendini onaran pod'lar, kademeli güncellemeler, gizli bilgi yönetimi ve tutarlı bir araç zinciri sunar. Arka uç servisleriniz, veritabanlarınız ve gözlemlenebilirlik yığınınız zaten bir kümede çalışıyorsa, broker'ı oraya eklemek her şeyi tek bir yerde tutar ve abonelerin ona küme ağı üzerinden ulaşmasını sağlar.
Ancak bir MQTT broker tipik bir durumsuz web servisi değildir. Bir MQTT broker'ın ne yaptığını anlamak nedenini açıklar: uzun ömürlü TCP bağlantıları tutar, çevrimdışı client'lar için oturum durumu saklar, retained message'ları depolar ve her mesajı eşleşen tüm abonelere dağıtır. Bu özellikler Kubernetes'in birkaç varsayımıyla çatışır.
Kubernetes Üzerinde Minimal Bir MQTT Broker
İşte parola doğrulamalı, küçük ama çalışan bir Mosquitto dağıtımı. Bir laboratuvar kümesi için uygundur ve hareketli parçaları hissetmenin iyi bir yoludur.
Önce bir parola dosyası oluşturup bir secret olarak saklayın:
mosquitto_passwd -c -b passwd device01 'change-this-password'
kubectl create namespace mqtt
kubectl -n mqtt create secret generic mosquitto-passwd --from-file=passwd
Ardından yapılandırmayı, dağıtımı ve servisi uygulayın:
apiVersion: v1
kind: ConfigMap
metadata:
name: mosquitto-config
namespace: mqtt
data:
mosquitto.conf: |
listener 1883
allow_anonymous false
password_file /mosquitto/secret/passwd
persistence true
persistence_location /mosquitto/data/
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mosquitto
namespace: mqtt
spec:
serviceName: mosquitto
replicas: 1
selector:
matchLabels:
app: mosquitto
template:
metadata:
labels:
app: mosquitto
spec:
terminationGracePeriodSeconds: 30
containers:
- name: mosquitto
image: eclipse-mosquitto:2
ports:
- containerPort: 1883
volumeMounts:
- name: config
mountPath: /mosquitto/config
- name: passwd
mountPath: /mosquitto/secret
- name: data
mountPath: /mosquitto/data
resources:
requests:
cpu: 100m
memory: 64Mi
limits:
memory: 256Mi
volumes:
- name: config
configMap:
name: mosquitto-config
- name: passwd
secret:
secretName: mosquitto-passwd
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: Service
metadata:
name: mosquitto
namespace: mqtt
spec:
type: LoadBalancer
selector:
app: mosquitto
ports:
- name: mqtt
port: 1883
targetPort: 1883
Yük dengeleyici bir adres aldıktan sonra kümenin dışından test edin:
mosquitto_sub -h <LOAD_BALANCER_IP> -p 1883 -u device01 -P 'change-this-password' -i k8s-sub -t 'test/#' -v
Bu çalışır, ama eksik olanlara dikkat edin: TLS, sertifika yenileme, izleme, uyarılar, yedekler ve herhangi bir yüksek erişilebilirlik biçimi. Asıl efor bunları eklemektedir.
Kubernetes'in MQTT İçin Çözmedikleri
Uzun Ömürlü Bağlantılar ve Kademeli Güncellemeler
Kademeli bir güncelleme pod'ları tek tek değiştirir. Bir HTTP servisi için bu görünmezdir. Bir broker içinse her pod yeniden başlatması o pod'daki tüm client'ların bağlantısını aynı anda keser ve hepsi aynı anda yeniden bağlanır. Düğüm boşaltmaları (drain), küme güncellemeleri ve autoscaler konsolidasyonu da aynı etkiyi tetikler. Rastgeleleştirilmiş üstel backoff kullanan cihazlara, bir PodDisruptionBudget'a ve broker değişiklikleri için bakım pencerelerine ihtiyacınız vardır.
Durum ve Depolama
Kalıcı oturumlar ve retained message'lar, pod yeniden zamanlamasından sağ çıkan depolamaya ihtiyaç duyar. Kalıcı birimlere sahip bir StatefulSet bunu tek bir düğüm için halleder; ancak birimler genellikle tek bir erişilebilirlik bölgesine bağlıdır ve bu da bir kesinti sırasında pod'un nereye taşınabileceğini sınırlar.
Yük Dengeleme Kümeleme Değildir
Tek düğümlü bir broker'ı bir yük dengeleyicinin arkasında üç kopyaya ölçeklemek bir küme oluşturmaz. Her kopya bağımsız bir broker olur ve birindeki yayıncı diğerindeki aboneye ulaşamaz. Gerçek yatay ölçekleme, kümeleme için tasarlanmış ve genellikle sağlayıcısının Helm chart'ı veya Kubernetes operatörüyle dağıtılan bir broker gerektirir. Açık kaynak MQTT broker karşılaştırması hangi projelerin bunu desteklediğini gösterir.
Kümenin Kenarında TLS
TLS'i bulut yük dengeleyicisinde veya broker'da sonlandırabilirsiniz. Broker'da sonlandırmak şifrelemeyi uçtan uca tutar, ancak sertifikaları bağlamak ve yenileme sırasında genellikle cert-manager ile yeniden yüklemek anlamına gelir. Yük dengeleyicide sonlandırmak daha basittir, ancak client sertifikalarına güveniyorsanız dikkat gerektirir.
Gözlemlenebilirlik
Broker metriklerini izleme yığınınıza aktarmanız, panolar oluşturmanız ve bağlantı düşüşleri, mesaj hızları ve kaynak kullanımı için uyarılar tanımlamanız gerekir. Önemli metrikler için MQTT broker izleme yazısına bakın.
Kubernetes ve Yönetilen Hizmet: Yan Yana
| Özellik | Kendi Kubernetes kümenizde broker | Yönetilen MQTT hizmeti |
|---|---|---|
| İlk kurulum | Manifestler veya Helm, yük dengeleyici, DNS, TLS | Portalda broker oluşturma |
| TLS sertifikaları | cert-manager veya benzerini siz kurarsınız | Sağlanır ve yenilenir |
| Güncellemeler | Siz planlar, test eder ve yayarsınız | Sağlayıcı tarafından yönetilir |
| Yüksek erişilebilirlik | Kümelenmiş broker artı çok bölgeli tasarım | Sağlayıcının sorumluluğu |
| İzleme | Metrikleri siz aktarır, uyarıları siz kurarsınız | Yerleşik konsol artı kendi kontrolleriniz |
| Güvenlik sıkılaştırma | Kimlik doğrulama, hız limitleri, yamaları siz yapılandırırsınız | Sağlayıcı platform korumalarını uygular |
| Esneklik | Broker ve eklentiler üzerinde tam kontrol | Sağlayıcının özellik seti dahilinde |
| Ağ yakınlığı | Servislerinizle aynı küme | Herkese açık uç noktalar veya hesabınızda BYOC |
Maliyet Kalemlerini Anlamak
Maliyetleri dürüstçe karşılaştırmak, işlem faturasının ötesine bakmayı gerektirir. Kubernetes'te barındırılan bir broker için maliyet şunları içerir:
- Altyapı: broker pod'ları için ayrılan düğüm kapasitesi, kalıcı birimler ve genel IP'li yük dengeleyiciler.
- Veri aktarımı: bulut dışındaki client'lara iletilen mesajlar için bulut sağlayıcınızdan çıkış (egress) trafiği.
- Kurulum için mühendislik zamanı: manifestler veya Helm değerleri, TLS otomasyonu, kimlik doğrulama, panolar ve uyarılar.
- İşletme için mühendislik zamanı: güncellemeler, güvenlik yamaları, kapasite gözden geçirmeleri, olay müdahalesi ve nöbet.
- Risk: yanlış yapılandırmadan kaynaklanan bir kesinti veya güvenlik olayının maliyeti.
Dedicated küme gibi yönetilen bir broker'da 3 ile 5 arasındaki kalemlerin çoğu aboneliğe taşınır ve alttaki altyapı yerine plan için ödeme yaparsınız. Faydalı bir alıştırma, ekibinizin 3. ve 4. kalemlere ayda harcayacağı saatleri tahmin etmek, tam yüklü bir saatlik ücretle çarpmak ve altyapı kalemine eklemektir. Ardından bu toplamı ConnectMQ Dedicated gibi yönetilen bir seçeneğin plan maliyeti veya teklifiyle karşılaştırın. MQTT broker toplam sahip olma maliyeti rehberimiz bu hesabı adım adım anlatır.
Kubernetes Ne Zaman Doğru Seçimdir?
Broker'ı Kubernetes üzerinde kendiniz çalıştırmak şu durumlarda mantıklıdır:
- Durum bilgili (stateful) iş yüklerini zaten iyi işleten bir platform ekibiniz varsa.
- Yönetilen bir hizmetin sunmadığı broker eklentilerine veya özelleştirmelerine ihtiyacınız varsa.
- Broker'ın air-gapped (internetten yalıtılmış) veya şirket içi bir kümede çalışması gerekiyorsa.
- Cihaz sayınız sabit ve iyi biliniyorsa.
Ekibiniz küçükse, MQTT kritik ama ana ürününüz değilse ya da hızla canlı ortama hazır olmanız gerekiyorsa genellikle yönetilen bir hizmet daha uygundur.
Orta Yol: Yönetilen, Ama Sizin Bulutunuzda
Sizi Kubernetes'e çeken şey broker'ı kendi bulut ortamınızda tutmaksa, üçüncü bir seçenek var. ConnectMQ BYOC, broker'ı sizin bulut hesabınızda çalıştırır ve ConnectMQ yönetir; böylece altyapı sizin olarak kalırken broker'ın güncellemeleri, sertifikaları ve izlenmesi sizin için yapılır. Dedicated planı ise sizin tarafınızda hiçbir altyapı işi olmadan izole bir küme sunar. İkisi de MQTT 3.1.1 ve 5.0 client'ları için Let's Encrypt sertifikalarıyla standart uç noktalar sunar: TCP 1883, TLS 8883, WebSocket 8083 ve /mqtt yolunda Secure WebSocket 8084.
ConnectMQ ile Başlayın
Bir Helm values dosyası daha yazmadan önce ücretsiz bir yönetilen MQTT broker deneyin. Kredi kartı gerekmeden app.connectmq.com adresinde bir Serverless broker oluşturun ve Kubernetes'te test ettiğiniz aynı client'ları ona yönlendirin. Ayrıca herkese açık MQTT test broker'ında anında deneme yapabilir ve barındırma modellerine daha geniş bir bakış için bulut MQTT broker rehberini okuyabilirsiniz.
Sık Sorulan Sorular
Mosquitto'yu Kubernetes'te kopya ekleyerek ölçekleyebilir miyim?
Hayır. Her kopya bağımsız bir broker olur ve mesajlar aralarında akmaz. Yatay ölçekleme, kümeleme için inşa edilmiş bir broker gerektirir.
MQTT client'larımın bağlantısı Kubernetes güncellemeleri sırasında neden kopuyor?
Pod yeniden başlatmaları ve düğüm boşaltmaları o pod'daki tüm bağlantıları kapatır. PodDisruptionBudget'lar, bakım pencereleri ve client tarafında jitter'lı yeniden bağlanma backoff'u kullanın.
TLS'i yük dengeleyicide mi yoksa broker'da mı sonlandırmalıyım?
Broker'da sonlandırmak şifrelemeyi uçtan uca tutar ve client sertifikası doğrulamasını korur; yük dengeleyicide sonlandırmak ise yönetmesi daha basittir. Kimlik doğrulama modelinize göre seçin.
Yönetilen bir broker Kubernetes'ten daha pahalı mı?
Yalnızca işlem maliyetini değil, kurulum, güncellemeler ve nöbet için mühendislik zamanı dahil toplam maliyeti karşılaştırın. Pek çok küçük ekip için yönetilen seçenek genel olarak daha az maliyetlidir.
