Kubernetes'te "Çalışıyor" ile "Production'a Hazır" Arasındaki Görünmeyen Mesafe

Hepimiz yaşadık. Uygulama laptopunuzda Docker'da mükemmel çalışıyor. Containerize ediyorsunuz, Kubernetes cluster'ını ayağa kaldırıyorsunuz ve bam—"deploy edildi" diyorsunuz. CTO heyecanlanıyor. Takım kutlama yapıyor.

Sonra gerçeklik çarpıyor.

Sizi "çalışıyor" noktasına getiren Kubernetes kurulumu, gerçek kullanıcıları, gerçek verileri ve sabah saat 3'te herkes uyurken sorunları karşılayabilen bir kurulum değildir.

"Kubernetes Üzerinde Çalışıyor" Production Değildir

Acı gerçek şu: geliştirme aşamasındaki Kubernetes kurulumu ile production Kubernetes kurulumu arasında, container orchestrator dışında neredeyse hiçbir ortak nokta yoktur.

Geliştirme ortamındaki Kubernetes şöyle görünür:

• Yerel minikube cluster'ları
• Sadece sizin makinenizde çalışan kendi kendine imzalı sertifikalar
• Sahte domain adları (*.127.0.0.1.nip.io)
• Ortam değişkenlerine dağılmış sabit kodlu kimlik bilgileri
• Bir kişinin manuel olarak helm install komutlarını çalıştırması
• "Monitoring'i sonra kurarız" anlayışı
• Hiç test edilmemiş yedeklemeler

Production Kubernetes ise tamamen farklı sorulara cevap vermek zorundadır:

• İnsan müdahalesi olmadan nasıl deploy ederiz?
• Şifreler gerçekte nerede yaşıyor ve kime erişim var?
• Depolama alanı başarısız olursa ne olur?
• Felaket anında yedeklemelerden geri yükleme yapabilir miyiz?
• Güvenlik politikalarına uygun muyuz?
• Kullanıcılar şikayet etmeden önce sorunları fark edebilir miyiz?

Bunlar lüks özellikler değildir. İşletim zamanında yapılan bir proje ile bir işletmenin bağımlı olduğu sistem arasındaki fark budur.

Gerçek İş: Kasıtlı Bir Sıra İzlemek

"Benim makinemde çalışıyor"dan "takım bunu güvenle işletebilir"e geçiş, öngörülebilir bir yolu takip eder. Yeni özellikler geliştirmiyorsunuz—operasyonel olgunluk geliştiriyorsunuz.

Aşama 1: Temel Bileşenleri Gerçekçi Şekilde Çalıştırın

Başta, temel bileşenlerin gerçekçi bir ortamda birbiriyle iletişim kurmasını sağlayın:

• Gerçek domain adları oluşturun (yerel test domain'leri değil)
• Uygun bir kimlik sağlayıcısını entegre edin (OIDC, SAML, veya ihtiyacınız olan her nedir)
• Kalıcı verileri cluster'ın dışına çıkarın—veritabanları ve nesne depolama alanlarının kendi yurtları olmalı
• Git'e kaydedilen YAML dosyalarına bağlı olmayan şifre yönetimini kurun

Bu aşama genellikle kullanıcılardan gizlidir. Kimse bunu deploy edilmiş olarak görmez. Ama bu olmadan, sonrasındaki her şey kırılgan kalır.

Aşama 2: Ürünü Kullanılabilir Yapın

Altyapı artık gerçek işlemleri desteklediğine göre, ürünün kendisi bununla uyumlu çalışmalıdır:

• Kullanıcı kimlik doğrulama akışları baştan sona çalışmalı
• Dosya yüklemeleri dayanıklı bir yere inmelidir
• Önbelleğe alma güvenilir çalışmalı, zaman aşımına uğramadan
• Ingress yönlendirmesi gerçek trafik düzenlerini işlemelidir

Geliştirme ortamınızın production'da kırılan varsayımlarını burada keşfedersiniz.

Aşama 3: Değişikliklerin Nasıl Gerçekleştiğini Kontrol Edin

Bu noktada "manuel Helm komutları" bir sorumluluk haline gelir. İhtiyacınız olan:

• GitOps ilkeleri: cluster durumu birinin kubectl geçmişinde değil, Git'te yaşar
• Herhangi bir şey deploy olmadan önce otomatik doğrulama
• Kim ne zaman neyi değiştirdi? Bunun açık denetim izi
• Bir şey yanlış gittiğinde geri alma yolları

GitOps sadece kolaylık hakkında değildir—güvenlik hakkındadır. Her değişiklik incelenebilir, test edilebilir ve geri alınabilir hale gelir.

Aşama 4: Kurtarma İmkanını Sağlayın

Çoğu takım burada başarısız olur. Yedeklemelerin var olduğunu varsayıp devam ederler.

Yedeklemeler eğer hiç onlardan geri yüklemezseniz işe yaramaz.

Gerçek production hazırlığı şu anlama gelir:

• Otomatik yedekleme programları (veritabanları, kalıcı birimler, yapılandırma)
• Test edilmiş geri yükleme prosedürleri (bir kez değil—düzenli olarak otomatikleştirilmiş)
• Açık RTO/RPO hedefleri (ne kadar hızlı kurtarabiliriz? ne kadar veri kaybetmeyi göze alabiliriz?)
• Tek bir kişinin hafızasına bağlı olmayan yazılı prosedürler

Aşama 5: İşlemleri Görünür Yapın

Son olarak, gerçekte ne olduğunu bilmeniz gerekir:

• Uygulama performansı, kaynak kullanımı, hata oranları hakkında metrikler
• Sistem sağlığını bir bakışta gösteren panolar
• Bir şey bozulduğunda doğru kişiyi uyandıran uyarı sistemi
• Sorunları çözmek için yeterince uzun süre saklanmış, aranabilir loglar

Gözlemlenebilirlik (observability), "umut etmek"ten "bilmek"e geçişinizi sağlar.

İntegrasyon Sorunu Göründüğünden Daha Büyük

İşte bizi şaşırtan şey: bu işin çoğunluğu aslında Kubernetes hakkında değildir.

Kubernetes container'dır—gerçek iş, çevresindeki her şeyin doğru şekilde entegre olmasını sağlamaktır:

• Kimlik, OIDC sağlayıcınızdan ingress katmanı üzerinden uygulama kodunuza akmalı
• Şifreler güvenli bir şekilde saklanmalı ama yine de doğru deployment'lar tarafından erişilebilir olmalı
• Depolama kalıcı olmalı ama aynı zamanda yedeklenmiş ve kurtarılabilir olmalı
• Yapılandırma versiyonlanmış, incelenebilir ve manuel adımlar olmadan dağıtılabilir olmalı
• Gözlemlenebilirlik logları, metrikleri ve izleri tüm bu sistemler arasında bağlamalı

Bunlardan herhangi biri kırıldığında, açık şekilde kırılır. Geri yüklenemeyen bir veritabanı yedeklemesi yedekleme değildir—gösterişin bir türüdür. Staging'de çalışan ama production'da çalışmayan bir kimlik doğrulama sistemi, saatlerce debugging'e mal olur.

Gerçek production işi, suyolları: tüm bu parçaların tutarlı, güvenli ve tekrarlanabilir şekilde birbiriyle iletişim kurmasını sağlamaktır.

GitOps: Sadece "Otomatik Deploy Et"ten Fazlası

GitOps'a geçtiğimizde, deployment otomasyonu bariz faydaydı. Ama gerçek kazanç örgütseldi.

GitOps bizi şunu yapmaya zorladı:

• Helm chart'larımızı tutarlı bir şekilde yapılandırmak
• Yapılandırma ile şifreler arasında açık bir ayrım yazmak
• Her pull request'te otomatik olarak çalışan doğrulama oluşturmak
• "Bu değişikliği kim onayladı ve ne zaman?" için bir iz oluşturmak

Anında, deployment artık birinin terminalinde anlık mesaj sohbeti sırasında gerçekleşen bir şey olmaktan çıktı. Denetlenebilir, incelenebilir bir sürece dönüştü.

Repository kaynak hakikat haline geldi. Bu düşündüğünüzden daha önemlidir.

Yedeklemeler Neden İki Kez Önemli Hale Geldi

Günün ilk gününden itibaren yedeklemelerimiz vardı. Sonra gerçekten birini geri yüklemeyi deneyelim dedik.

İşte o zaman yedekleme scriptlerimizin dosya oluşturduğunu ama test etmediğini keşfettik. Yıllar of verisi vardık ama geri getiremiyorduk.

Geri yükleme testini otomatikleştirdiğimiz zaman değişim meydana geldi. Ayda bir kez, bir yedeklemeyi staging cluster'ına geri yüklerdik, verinin bozulmadığını kontrol ederdik ve siler dik. Bu otomatik çalışan prosedür, kurtarma hakkında nasıl düşündüğümüzü tamamen değiştirdi.

Bir geri yükleme testi yapmadığınız sürece, yedeklemeler sadece iyimserlik. Otomatik geri yükleme testleri onları güvene dönüştürür.

Sıkıcı Gerçeklik

Bunların hiçbiri göz alıcı değildir. Burada hiç özellik yok. Kullanıcılarınız bu işi görmeyecekler.

Ama bu adımları atlamaya çalışan her takım bunun bedelini ödemiştir. GitOps olmadan deploy eden takım hala manuel kubectl komutlarını yönetiyor. Geri yüklemeleri test etmeyen takım, felaket çıktığında afet planlarının kurgu olduğunu keşfetti. Gözlemlenebilirlik kurmayan takım gözü kapalı uçmuş.

Production hazırlığı tek bir büyük proje değildir—güvenilir bir şey oluşturacak şekilde yığılan küçük, sıkıcı, zorunlu kararların bir dizisidir.

Kubernetes kurulumunuz hala geliştirme aşamasındaysa, iyi haber şu: production'a giden yol bilinmektedir. Ne olması gerektiğini biliyorsunuz. Sadece bunu kasıtlı, doğru sırada ve test adımlarını atlamadan yapmak meselesidir.

Production'a hazır görünüşü:

• Deployment, manuel komutlarla değil Git commit'leriyle gerçekleşir
• Şifreler, YAML dosyalarına dağılmadan merkezi olarak yönetilir
• Yedeklemeler otomatik test edilir, sadece varsayılmaz
• Kullanıcı akışları gerçek kimlik sistemleriyle baştan sona çalışır
• Operasyon tahminden değil gözlemlenebilirlikten bilir
• Değişiklikler denetlenebilir, geri alınabilir ve güvenlidir

Bunu inşa etmeye değer.