OpenShift ile Kurumsal Kubernetes Platformu Nasıl İşletilir?

OpenShift'i Kubernetes'ten ayıran işletme katmanı

OpenShift, Kubernetes üzerine kurulu bir kurumsal platformdur. Saf Kubernetes kümesinde kimlik doğrulama, ağ giriş noktası, imaj yönetimi, izleme ve güncelleme gibi parçaları ekibin kendisi seçip birleştirir. OpenShift bu parçaların önemli bir kısmını platformun içinde hazır ve birbirine bağlı sunar. Dolayısıyla işletme görevi "parçaları seçmek" değil, "platformun kurallarını ve sınırlarını doğru ayarlamak" haline gelir.

Bu fark, kimin ne yaptığını da değiştirir. Platform yöneticisi kümeyi, kullanıcı kaynaklarını, güvenlik politikalarını ve yükseltmeleri yönetir. Uygulama ekipleri ise kendi projelerinin içinde uygulama yayınlar. İyi işletilen bir OpenShift ortamında uygulama ekibi platform sınırlarının farkındadır ama sürekli yöneticiye başvurmak zorunda kalmaz.

Kubernetes ile OpenShift arasındaki karar sorusu ayrı bir konudur; burada odak, OpenShift'i seçmiş bir kurumun platformu gün be gün nasıl işlettiğidir.

Mimariyi okumak: küme bileşenleri ve düğüm rolleri

İşletmenin ilk adımı kümenin neyden oluştuğunu bilmektir. Kontrol düzlemi kümeyi yöneten bileşenleri barındırır; işçi düğümler uygulamaları çalıştırır. Kümede çalışan platform servisleri (giriş yönlendirmesi, dahili imaj kaydı, izleme yığını) ayrı bir ad alanı grubunda yaşar ve bunların sağlığı doğrudan tüm uygulamaları etkiler.

Gündelik kontrol için şu soruları sorun: • Düğümler hazır durumda mı, kaynak baskısı altında olan düğüm var mı? • Platform servislerinin pod'ları sağlıklı mı? • Kümenin operatörleri güncel ve sorunsuz durumda mı? • Depolama ve ağ bileşenlerinde tekrarlayan hata var mı?

Bu kontrolleri komut satırı aracıyla (oc) ve web konsoluyla yapabilirsiniz. Komut satırı otomasyon ve betikleme için, konsol ise hızlı görsel durum ve yeni başlayanlar için uygundur. Sağlam bir işletme alışkanlığı, kontrolleri elle yapmak yerine izleme ve uyarıya bağlamaktır.

Kimlik, kullanıcı ve yetkilendirmeyi doğru kurmak

Kurumsal bir platformda ilk güvenlik hattı kimdir sorusunun cevabıdır. OpenShift, kullanıcı kimliğini dış bir kimlik sağlayıcıya (örneğin kurumun dizin hizmeti) bağlayabilir; böylece kullanıcı hesapları merkezi yönetilir ve ayrılan çalışanın erişimi tek yerden kapanır. Kullanıcıları tek tek değil gruplar halinde yönetmek, yetki değişikliklerini hızlandırır ve hata payını azaltır.

Yetkilendirme rol tabanlıdır. Bir kullanıcıya ya da gruba, belirli bir proje içinde belirli bir rol atanır: yalnızca görüntüleyen, uygulama dağıtabilen ya da projeyi yöneten. Küme geneli yetkiler ise çok dar tutulmalıdır. Örnek bir uygulama: geliştiricilere yalnızca kendi proje alanlarında dağıtım yetkisi verin, küme yöneticisi rolünü ise çok az sayıda ve izlenen hesaba bırakın.

Sık yapılan hata, kolaylık adına geniş yetki dağıtmaktır. Sorun çıktığında hangi hesabın neyi değiştirdiğini izlemek zorlaşır. Yetki kararlarını kayıt altına almak ve düzenli aralıklarla gözden geçirmek bu riski küçültür.

Proje yönetimi ve kaynak kontrolü

OpenShift'te proje, bir ekibin ya da uygulamanın çalışma alanıdır. Her proje kendi kaynaklarını, rollerini ve sınırlarını taşır. Bu yapı "çok kiracılı" bir kümede ekiplerin birbirini etkilemesini engeller. Proje oluştururken bir isimlendirme kuralı belirlemek (ekip, uygulama, ortam) ileride envanter ve fatura dağıtımı gibi işleri kolaylaştırır.

Kaynak kontrolü birbirini tamamlayan araçlarla yapılır. Kota, bir projenin toplamda ne kadar işlemci, bellek ve nesne kullanabileceğini sınırlar. Sınır aralığı (limit range) ise tek bir pod'un makul bir kaynak isteği olup olmadığını denetler ve tanımlanmamışsa varsayılan değerler atar. Birlikte kullanıldıklarında tek bir ekibin hatalı bir dağıtımla kümenin tamamını tüketmesini önler.

Örnek senaryo: bir uygulama ekibi test ortamında bellek sızıntısı olan bir sürümü dağıtır. Kota tanımlıysa sorun yalnızca o projeyle sınırlı kalır; kota yoksa diğer projelerin pod'ları da yer bulamayıp bekleyebilir. Kotaları ortam tipine göre ayrı belirlemek ve düzenli gözden geçirmek, platform işletiminin temel rutinlerindendir.

Güvenlik bağlamları ve politikalar

OpenShift varsayılan olarak konteynerlerin nasıl çalışabileceği konusunda katıdır. Güvenlik bağlamı kısıtlamaları, bir pod'un hangi kullanıcı kimliğiyle çalışabileceğini, ayrıcalıklı olup olamayacağını ve düğümün hangi kaynaklarına erişebileceğini belirler. Bu, saf Kubernetes'e alışkın ekipler için ilk dağıtımda sürpriz olabilir: kök kullanıcıyla çalışmak isteyen bir imaj kabul edilmeyebilir.

Doğru yaklaşım, kısıtlamayı gevşetmek yerine imajı kısıtlamaya uyumlu hale getirmektir. Gerçekten özel bir ihtiyaç varsa, bunu ayrı bir hizmet hesabına ve gerekçelendirilmiş, sınırlı bir politikaya bağlayın; genel çözüm olarak geniş bir istisna açmayın.

Ağ politikaları da güvenliğin parçasıdır. Projeler arası trafiği varsayılan olarak daraltıp yalnızca gereken yönlere izin vermek, bir projedeki ihlalin yayılmasını zorlaştırır. Politika değişikliklerini önce test projesinde denemek ve sonra üretime uygulamak, kesinti riskini düşürür.

Uygulama yayınlama ve build süreçleri

Platformun bir diğer değeri, kaynak koddan çalışan uygulamaya giden yolu standartlaştırmasıdır. Ekip kaynak kodu ya da hazır bir konteyner imajını platforma verir; platform imajı üretir, kaydeder ve uygulamayı proje içinde çalıştırır. Uygulamaya dışarıdan erişim için bir rota tanımlanır ve platformun giriş yönlendiricisi trafiği ilgili servise iletir.

Build tarafında dikkat edilecek noktalar: • Temel imajları güvenilir kaynaklardan seçin ve düzenli güncelleyin. • Build sırasında kullanılan gizli bilgileri (parola, anahtar) imajın içine değil, platformun gizli nesnelerine koyun. • Her build'in hangi kaynak sürümünden üretildiğini izlenebilir tutun. • Başarısız build'lerin nedenini kayıtlardan okuyup tekrar eden kalıpları giderin.

Dağıtım stratejisi de bir işletme kararıdır. Kademeli güncelleme, yeni sürümü yavaş yavaş devreye alır ve sorun görülürse eski sürüme dönmeyi mümkün kılar. Hangi uygulamada hangi stratejinin uygun olduğuna, uygulamanın kesinti toleransına göre karar verin.

Operatörler, izleme ve yükseltme planı

OpenShift'te platform servisleri ve birçok dış bileşen operatörler aracılığıyla kurulur ve yönetilir. Operatör, bir uygulamanın kurulum, yapılandırma ve güncelleme bilgisini kümeye taşır. Yöneticinin görevi, hangi operatörlerin kurulacağına karar vermek, güncelleme kanalını seçmek ve operatörlerin sağlık durumunu izlemektir.

İzleme için platformun yerleşik izleme yığınını temel alın: küme metrikleri, uyarı kuralları ve log toplama. Kapasite yönetimi bu verilerden beslenir: düğüm kullanım eğilimi, proje bazlı tüketim ve bekleyen pod'lar kapasite artırım kararının dayanağıdır. Uyarı kurallarını gürültü üretmeyecek şekilde sade tutun; her gece çalan bir uyarı yakında yok sayılır.

Yükseltme planı olgun bir ekibin ayırt edici özelliğidir. Önce bir test kümesinde deneme, ardından değişiklik penceresi, yedekleme ve geri dönüş planı gelir. Kümenin yapılandırma yedeğini ve uygulama verilerinin yedeğini ayrı düşünün. Bir yükseltmeyi duyuru, ön kontrol, uygulama ve doğrulama adımlarıyla yazılı bir kontrol listesine bağlamak, sürpriz sorunları azaltır.

Bu beceriyi Mindset programında nerede çalışırsınız?

Mindset kataloğundaki OpenShift ile Kurumsal Kubernetes Platformu eğitimi, platform mühendisleri, DevOps ekipleri ve altyapı yöneticileri için tasarlanmış bir yapıya sahiptir. Modül başlıkları OpenShift mimarisi ve küme bileşenleri, kimlik ve yetkilendirme, proje ve kaynak kontrolü, güvenlik bağlamları, uygulama yayınlama ve build süreçleri, operatörler ve platform servisleri, izleme ve kapasite, yükseltme ve yedekleme planını kapsar.

Kurumsal ekipler için bu sıralama, platformu devralacak bir grubun hem ortak bir sözlük hem de ortak bir işletme rutini oluşturmasına uygundur. Güncel dönem ve içerik ayrıntıları eğitim sayfasında yer alır.