Red Hat Bulut Çözümleri: Hibrit Bulut Mimarisinin Teknik Temelleri

Kurumsal BT ekiplerinin çoğu, “bulut” deyince tek bir altyapıyı ya da sağlayıcıyı aklına getiriyor. Oysa production gerçekliği çok daha karmaşık: on-premise veri merkezleri, özel bulutlar ve birden fazla genel bulut sağlayıcısı aynı anda devrede. Bu ortamda tutarlı bir yönetim katmanı olmadan işleri yürütmek giderek zorlaşıyor.

Red Hat, bu sorunu ürün bazında değil mimari düzeyde çözmeye çalışıyor. RHEL’den OpenShift’e, Ansible’dan Advanced Cluster Management’a uzanan portföy, birbirine entegre çalışacak şekilde tasarlanmış. Bu yazıda söz konusu katmanları teknik detaylarıyla ele alıyoruz.

Mimari Katmanlar: Hangi Katmanda Neler Yer Alıyor?

Red Hat’in hibrit bulut yaklaşımını anlamak için önce katman yapısını netleştirmek gerekiyor:

• Altyapı katmanı: Red Hat Enterprise Linux (RHEL) ve OpenShift Virtualization
• Platform katmanı: Red Hat OpenShift Container Platform (OCP)
• Yönetim katmanı: Red Hat Advanced Cluster Management (ACM) ve Insights
• Otomasyon katmanı: Red Hat Ansible Automation Platform (AAP)

Her katman bağımsız kullanılabilir, ancak birlikte çalıştıklarında ortak bir control plane oluşturarak altyapının tüm yaşam döngüsünü tek noktadan yönetmeyi mümkün kılıyorlar.

Katman 1: Red Hat Enterprise Linux

RHEL, üzerinde her şeyin koştuğu temel işletim sistemi katmanı. Ama bu tanım biraz sınırlı kalıyor; çünkü modern RHEL, salt bir Linux dağıtımının ötesine geçmiş durumda.

Image Mode ve Bootc

RHEL 9.x ile birlikte gelen image mode (bootc), işletim sistemini konteyner imajı gibi yönetmeye imkan tanıyor. Paket tabanlı güncellemeler yerine tüm OS katmanı bir OCI imajı olarak versiyonlanıp deploy ediliyor:

Bu yaklaşımın pratikte ne faydası var? OS konfigürasyonu Git’e giriyor, rollback atomik hale geliyor ve veri merkezi ile edge lokasyonlar arasında OS tutarlılığı garanti altına alınıyor. Özellikle onlarca lokasyonu olan kurumlarda bu fark ciddi operasyonel kazanım sağlıyor.

SELinux ve Kernel Güvenliği

RHEL üzerinde SELinux varsayılan olarak enforcing modda geliyor. OpenShift node’larında kullanılan RHEL CoreOS (RHCOS) ortamında ise SELinux politikaları OCP tarafından otomatik yönetiliyor. Bunun anlamı şu: bir pod, host kernel’ına yetkisiz erişim sağlamaya çalışırsa işletim sistemi bunu sistem düzeyinde engelliyor; uygulama katmanına kadar yükselmesini beklemeye gerek kalmıyor.

İlginizi Çekebilir: Red Hat OpenShift: Kubernetes’ten Kurumsal Platforma Geçiş Rehberi

Katman 2: OpenShift Container Platform

Cluster Anatomisi

Bir OCP cluster’ı üç düğüm tipiyle çalışıyor. Minimum kaynak gereksinimlerini ve görev dağılımını aşağıda bulabilirsiniz:

etcd, cluster’ın tüm nesne tanımlarını (Deployment, Service, ConfigMap vb.) saklayan dağıtık anahtar-değer deposudur. Üretim ortamında etcd disk I/O gecikmesinin 10 ms altında kalması kritik önem taşıyor; bu yüzden etcd node’larında NVMe SSD kullanımı neredeyse zorunlu hale gelmiş durumda.

MachineConfig ile Node Yönetimi

OCP, Kubernetes API’sini genişleten 400’den fazla Custom Resource Definition (CRD) ile kuruluyor. Bunların en güçlülerinden biri MachineConfig. Düğümlerin OS düzeyi konfigürasyonunu Ignition mekanizması aracılığıyla merkezi olarak tanımlamanızı sağlıyor:

Bu konfigürasyon tüm worker node’larına uygulanıyor ve MachineConfigOperator sürekli denetim yapıyor. Bir node sapma gösterirse otomatik olarak yeniden yapılandırılıyor. Kısacası node’lar konfigürasyonun dışına çıkamıyor.

OVN-Kubernetes ile Ağ Yönetimi

OCP 4.x, varsayılan CNI eklentisi olarak OVN-Kubernetes kullanıyor. Open vSwitch üzerine inşa edilmiş bu SDN çözümü kurumsal ortamlar için önemli ağ yetenekleri sunuyor:

• NetworkPolicy: Namespace ve pod düzeyinde L3/L4 ağ izolasyonu
• EgressIP: Belirli namespace’lerden çıkan trafiği sabit kaynak IP üzerinden yönlendirme
• EgressFirewall: Namespace’lerin ulaşabileceği dış CIDR bloklarını kısıtlama
• IPsec: Pod-to-pod trafiğini kernel düzeyinde şifreleme

Finans sektöründen somut bir örnek vermek gerekirse: ödeme uygulamasının koştuğu namespace’in yalnızca iç ağa ve belirli bir ödeme ağ geçidine çıkmasına izin verip diğer tüm internet trafiğini kesmek için şu EgressFirewall nesnesi kullanılabilir:

Depolama: CSI ve OpenShift Data Foundation

OpenShift, depolama sistemleriyle Container Storage Interface (CSI) sürücüleri üzerinden konuşuyor. Kurumsal ortamlarda NetApp Trident (ONTAP tabanlı NFS/iSCSI/NVMe-oF), Pure Storage PSO (FlashArray/FlashBlade) ve OpenShift’in kendi yazılım tanımlı depolama çözümü ODF yaygın olarak tercih ediliyor.

ODF, Ceph’i üç veya daha fazla node üzerinde çalıştırarak üç farklı depolama tipi sunuyor: paylaşımlı dosya sistemi için CephFS (RWX modu), blok depolama için RADOS Block Device (RWO modu) ve S3-uyumlu nesne depolama için Ceph Object Storage. Bu üçü aynı anda, aynı cluster üzerinden kullanılabiliyor.

İlginizi Çekebilir:Yapay Zekâda Güvenilirlik ve Kontrol

Katman 3: Advanced Cluster Management

Çoğu kurumsal ortamda tek bir OpenShift cluster’ı yetmiyor. Production, staging, disaster recovery, edge lokasyonlar ve farklı cloud sağlayıcılarındaki cluster’lar bir arada yönetilmek zorunda kalıyor. Red Hat Advanced Cluster Management (RHACM) bu karmaşıklığı tek bir yönetim düzlemine indirgiyor.

Hub-Spoke Tasarımı

RHACM, hub cluster üzerinde çalışıyor ve diğer cluster’ları ManagedCluster nesneleri olarak yönetiyor. Her spoke cluster’a deploy edilen klusterlet agent, hub ile güvenli iletişimi sağlıyor:

Policy-as-Code ile Merkezi Uyumluluk

RHACM’ın pratik değeri en çok Policy Framework’te görünüyor. Güvenlik ve uyumluluk politikaları merkezi olarak tanımlanıp tüm cluster’lara dağıtılıyor; ihlaller gerçek zamanlı raporlanıyor. Aşağıdaki örnek, yönetilen tüm cluster’larda privileged pod’ları engelliyor:

enforce modunda bu politikayı ihlal eden pod’lar hiçbir cluster’da ayağa kalkamıyor. Politika merkezi Git reposunda yönetiliyor, değişiklik geçmişi tam olarak izlenebilir oluyor.

GitOps ile Uygulama Dağıtımı

RHACM, Argo CD ile entegre çalışarak uygulama dağıtımını GitOps prensipleriyle yönetiyor. Git reposundaki değişiklik hedef cluster’lara otomatik olarak sync ediliyor. Bu sayede kim hangi değişikliği ne zaman yaptı sorusunun yanıtı her zaman commit geçmişinde bulunuyor.

Katman 4: Ansible Automation Platform

Kubernetes harika bir platform, ancak her şeyi konteyner olarak çalıştırmak mümkün değil. Ağ cihazları, bare-metal sunucular, legacy VM’ler ve güvenlik duvarları hala geleneksel yöntemlerle yönetilmek zorunda. Ansible Automation Platform bu boşluğu dolduruyor.

AAP 2.x Bileşenleri

AAP 2.x ile mimari mikro-servis yapısına geçti. Şu an dört temel bileşenden oluşuyor:

• Automation Controller: AWX/Tower’ın kurumsal versiyonu; iş akışlarını, envanterleri ve kimlik bilgilerini yönetiyor
• Automation Hub: Sertifikalı ve özel Ansible koleksiyonları için dahili registry
• Event-Driven Ansible (EDA): Kafka, webhook ve alert gibi harici olaylara dayalı otomasyon tetikleme
• Automation Mesh: Edge, DMZ ve uzak veri merkezlerinde güvenli otomasyon çalıştırma altyapısı

Event-Driven Ansible ile Reaktif Operasyon

EDA’nın pratikte nasıl çalıştığını bir örnekle görmek en iyisi. Aşağıdaki rulebook, Prometheus’tan gelen disk doluluk uyarısını dinliyor ve ilgili sunucuda otomatik olarak log temizleme playbook’unu tetikliyor:

Alert geldiği anda playbook çalışıyor ve operasyon ekibi yalnızca bir bildirim alıyor. Gece yarısı uyanma, terminale bağlanma, manuel müdahale yok.

İlginizi Çekebilir: Modern Veri Merkezlerinde Görünürlük: Cisco MDS SAN Analytics ile Tanışın

Cluster Provisioning Otomasyonu

AAP ile OpenShift’i birleştirmenin en değerli kullanım senaryolarından biri yeni cluster kurulumunun tam otomasyonu. Ansible playbook’ları şu adımları sıralı ve tekrarlanabilir biçimde yürütüyor:

• vSphere veya bare-metal üzerinde VM ve node oluşturma
• DNS ile load balancer kayıtlarını yapılandırma
• OpenShift IPI ya da UPI kurulumunu başlatma
• Yeni cluster’ı RHACM hub’a kaydetme
• ODF, ACM Agent ve Logging operatörlerini kurma
• Güvenlik politikalarını uygulama

Yeni bir cluster, konfigürasyonu Git’te tanımlı, politikaları merkezi olarak yönetilen ve gözlemlenebilirlik stack’i hazır şekilde production’a alınmış oluyor.

Red Hat Insights: Sorun Çıkmadan Önce Görmek

Red Hat Insights, OpenShift ve RHEL cluster’larından telemetri verisi toplayarak konfigürasyon sorunlarını, CVE’leri ve uyumluluk ihlallerini önceden tespit ediyor. Dört temel analiz modülüyle çalışıyor:

• Advisor: Konfigürasyon önerileri ve risk değerlendirmesi
• Vulnerability: CVE’lerin cluster üzerindeki somut etki analizi
• Compliance: CIS Benchmark ve DISA STIG uyumluluk raporları
• Drift: Zaman içinde oluşan konfigürasyon sapmalarının tespiti

Telemetri verisinin dışarı çıkmasını istemeyen kurumlar için Insights verisi Satellite ya da RHACM ile entegre edilerek yerel veri merkezinde işlenebiliyor.

Sekom’un Teknik Yaklaşımı

Sekom, Red Hat projelerinde kurulum ve teslimle sınırlı kalmayan bir metodoloji izliyor. Süreç üç aşamada ele alınıyor.

Mimari Tasarım: Her proje, müşterinin mevcut BT altyapısını (vSphere sürümü, ağ topolojisi, storage backend, LDAP/AD yapısı) analiz eden bir Discovery Workshop ile başlıyor. Buradan çıkan teknik mimari belgesi; OCP cluster boyutlandırması, network CIDR planlaması, storage class tanımları ve operatör listesini kapsıyor.

Day-2 Operasyon: Kurulum sonrası operasyonlar çoğu zaman göz ardı ediliyor. Sekom, AAP playbook’larıyla cluster sertifika rotasyonu, etcd yedekleme, node scale-out ve OpenShift minor versiyon güncellemelerini tamamen otomatize ediyor.

Gözlemlenebilirlik Stack’i: Her OpenShift kurulumuna entegre gözlemlenebilirlik altyapısı eşlik ediyor: Prometheus ve Alertmanager metrik toplama için, OpenShift Logging (Loki ya da Elasticsearch tabanlı) log toplama için, Jaeger ya da Tempo distributed tracing için. Bu üçlü bir arada olduğunda operasyon ekipleri L1 sorununu uygulama katmanı bottleneck’ine kadar izleyebiliyor.

Red Hat’in portföyü bir arada çalıştığında kurumsal altyapı gerçek anlamda kod ile yönetilen, politikalar tarafından denetlenen ve kendini onaran bir yapıya dönüşüyor. Bu, kağıt üzerindeki bir söylem değil; doğru mimari kararlar ve operasyon modeli ile ulaşılabilir bir hedef.

Türkiye’nin yetkili Red Hat iş ortağı Sekom, bu teknik mimarinin tasarımından işletmeye alınmasına kadar tüm süreçte kurumsal müşterilerine eşlik etmektedir. Teknik mimari danışmanlık ve ücretsiz cluster boyutlandırma analizi için aşağıdaki formu doldurabilirsiniz.