Kubernetes'e Taşınırken Yapabileceğiniz En Büyük 3 Hata
15 Nisan 2024 Pazartesi
Kubernetes'e taşınırken ters gidebilecek her şeyden nasıl kaçınabiliriz.
Son on yıl, buluta özgü teknolojiye, özellikle de Kubernetes'e doğru ilerlemeyi hızlandıran bir dijital dönüşüm dalgası getirdi. Bu hareketin faydaları (ve dezavantajları!) hakkında konuşabiliriz. Cloud-native dönüşümünün daha az tuzlu tarafı hakkında konuşmak için buradayız. Daha da açmak gerekirse Kubernetes'e taşınırken ters gidebilecek her şeyden nasıl kaçınılacağını tartışacağız.
Hata #1: Kubernetes'i komut satırından yönetme:
Kubernetes dağıtımları, onları ilk çalıştırdığınızda neredeyse sihir gibi hissettiriyor. Çalıştırmak istediğiniz uygulamayı belirtmek için kısa bir YAML dosyası kullanırsınız ve Kubernetes bunu yapar. Dosyada bir değişiklik yaptığınızda neredeyse gerçek zamanlı olarak güncellenecektir.
Ancak kubectl ne kadar güçlü ve onu kullanarak Kubernetes'i keşfetmek için ne kadar öğretici olursa olsun, kubectl'e çok fazla güvenmemelisiniz. Tabii ki, Kubernetes'teki sorunları gidermeniz gerektiğinde ona (veya harika kuzeni, k9s'a) geri döneceksiniz, ancak bunu kümenizi yönetmek için kullanmayın.
Kubernetes, Kod Olarak Yapılandırma paradigması için yapıldı ve tüm bu YAML dosyaları bir Git deposuna aittir. İstediğiniz tüm değişiklikleri bir repo'ya taahhüt etmeli ve otomatik bir üretim hattının üretimdeki değişiklikleri dağıtmasını sağlamalısınız. Seçeneklerinizden bazıları şunları içerir:
- Jenkins ve CircleCI gibi Sürekli Entegrasyon (CI) araçlarını kullanma.
- CodeFresh ve Harness gibi Sürekli Dağıtım (CD) araçlarını kullanma.
- Flux gibi GitOps araçlarını kullanmak.
Hata #2: Kaynaklar hakkında her şeyi unutmak
Tüm iş yüklerinizin Kubernetes'in tüm gücü ve Kod Olarak Yapılandırma ile çalışır durumda olduğunu varsayalım. Ama şimdi, sanal makineleri değil, konteynerleri düzenliyorsunuz. İhtiyaç duydukları CPU ve RAM'i almalarını nasıl sağlıyorsunuz? Kaynak tahsisi yoluyla!
Kaynak istekleri
Kaynak istekleri ayarlamayı unutursanız ne olur?
Kubernetes, tüm Pod'larınızı (Kubernetes-speak'deki "iş yükleri") bir avuç düğüme paketleyecektir. İhtiyaç duydukları kaynakları alamayacak ve küme gerektiği gibi kendini büyütemeyecektir.
Kaynak istekleri nelerdir?
Kaynak istekleri, zamanlayıcının uygulamanızın kaç kaynak tüketmesini beklediğinizi bilmesini sağlar. Düğümlere bölmeler atarken, Kubernetes bunları tüm gereksinimlerinin düğümün kaynakları tarafından karşılanması için bütçeler.
Kaynak sınırları:
Kaynak sınırları belirlemeyi unutursanız ne olur?
Tek bir bölme, düğümde bulunan tüm CPU'yu veya belleği tüketebilir ve komşularının CPU'dan mahrum kalmasına veya Bellek Dışı hataları almasına neden olabilir.
Kaynak sınırları nelerdir?
Kaynak sınırları, konteyner çalışma zamanının uygulamanızın kaç kaynak tüketmesine izin verdiğinizi bilmesini sağlar. CPU sınırı için, uygulamanız bu kadar CPU süresi elde edebilecek, ancak daha fazla olmayacaktır. Ne yazık ki (uygulama için), bellek sınırına ulaşırsa, konteyner çalışma zamanı tarafından OOMKilled olacaktır.
Öyleyse devam edin ve konteynerlerinizin her biri için istekler ve sınırlar tanımlayın. Emin değilseniz, sadece bir tahminde bulunun ve güvenli tarafın daha yüksek olduğunu unutmayın. Emin olsanız da olmasanız da, bulut sağlayıcınızı veya APM araçlarınızı kullanarak bölmeleriniz ve konteynerleriniz tarafından gerçek kaynak kullanımını izlediğinizden emin olun.
Hata #3: Geliştiricileri geride bırakmak
- Değişmez altyapı ve kusursuz yükseltmeler.
- Kolay ölçeklenebilirlik.
- Yüksek erişilebilirlik,
- Kendi kendini iyileştiren hizmetler.
Kubernetes size doğrudan kutudan çıkar çıkmaz çok sayıda değer sağlar. Ne yazık ki, bu değer ürününüz üzerinde çalışan geliştiriciler için bir öncelik olmayabilir. Geliştiricilerinizin başka endişeleri vardır.
- Kodumu nasıl oluşturur ve çalıştırırım?
- Kodumun geliştirme, test etme ve entegrasyonda ne yaptığını nasıl anlayabilirim?
- QA ve üretim ortamlarında bildirilen hataları nasıl araştırabilirim?
Birçok geliştirme ve test iş yükü buluta taşındığı için geliştirme ortamlarını yerel olarak çalıştırmak çok daha zordur. Geliştiricilerin güvendikleri kod düzeyinde görünürlük genellikle bu ortamlarda zayıftır ve uygulamaya ve dosya sistemine doğrudan erişim neredeyse imkansızdır.
Detaylı bilgi İçin lütfen tıklayınız.