Gantek
Openshift Updates

Openshift Updates

 

1. OpenShift Updates

1.1. Cluster Update Process

Red Hat OpenShift Container Platform 4, Red Hat Enterprise Linux CoreOS'u kullanarak birçok yeni özellik ekliyor. Red Hat, cluster’ı ve işletim sistemini güncellemek için upgrade path sağlayan yeni bir software distribution sistemini piyasaya sürdü. Bu yeni sistemle OpenShift cluster’lar over-the-air olarak da nitelendirilen (OTA) update’ler gerçekleştirebilir. Bunun için kalıcı bir internet bağlantısı gereklidir.

OTA'ya yönelik bu software distribution sistemi, bir cluster’ı  belirli bir versiyona güncellemek için controller manifestlerini, cluster rollerini ve diğer kaynakları yönetir. Bu özellik sayesinde bir cluster 4.14.x versiyonunu sorunsuz bir şekilde çalıştırabilir. OTA ile bir cluster, en son bug fix ve security patch’ler kullanıma sunuldukça kullanabilir. OTA, upgrade’ler nedeniyle meydana gelen kesinti sürelerini önemli ölçüde azaltır.

Red Hat, bu hizmeti https://console.redhat.com/openshift adresinde, cluster image’larını da https://quay.io  adresinde tutar. Tüm OpenShift cluster’ların lifecycle yönetimi için tek bir arayüz kullanırsınız. Ayrıca, OTA ile ara versiyonları atlayarak daha hızlı update yapabilirsiniz. Örneğin 4.14.1'den 4.14.3'e update yaparak 4.14.2'yi atlayabilirsiniz.

 

Resim: cloud.redhat.com üzerinden cluster’ların yönetimi


Servis, belirli update’ler için cluster uygunluğuna karşılık gelen upgrade path’leri tanımlar. Upgrade path’ler, update channel’larına aittir. Bir channel, upgrade path’in bir temsili olarak düşünülebilir. Channel, update sıklığını ve kararlılığını kontrol eder. OTA policy engine; channel’ları, upgrade path içindeki belirli versiyonlara yönelik bir dizi pointer (işaretçi) olarak temsil eder.

Bir channel name şu bölümlerden oluşur:

  • tier (release candidate, fast, stable ve extended update support),
  • major version (4)
  • minor version (.12).

Örnek bir channel name şunları içerir:

  • candidate-4.14
  • fast-4.14
  • stable-4.14
  • eus-4.14


Her channel, belirli bir cluster version için patch’ler sunar.

Resim: Openshift Container Platform Örnek Update Path


Şimdi bunları biraz açıklayalım:

Candidate Channel:  OpenShift Container Platform'un sonraki versiyonunda feature acceptance testlerine yönelik güncellemeler sunar. Candidate channel versiyonlar daha fazla kontrole tabi tutulur ve kalite standartlarını karşıladıklarında fast veya stable channel’lara yükseltilir. Red Hat tarafından unsupported olan tek channel’dır.

Fast Channel: Fast channel, Red Hat'in verilen versiyonu “general availability release” olarak ilan ettiği anda update’leri sunar. Red Hat, bu channel’da yayınlanan update’leri destekler ve geliştirme ve QA (quality assurance) ortamları için en uygunudur.

Stable Channel: Red Hat support ve site reliability engineering (SRE) ekipleri, fast channel’dan gelen update’lerle operasyonel cluster’ları monitor eder. Operasyonel cluster’lar, ek test ve doğrulamayı geçerse fast channel’daki update’ler stable channel’da etkinleştirilir. Red Hat, bu channel’da yayınlanan update’leri destekler ve production ortamlarına en uygun olanıdır.

Extended Update Support Channel: OpenShift Container Platform 4.8'den başlayarak Red Hat, tüm çift sayılı minor release’leri (örneğin, 4.8, 4.10, 4.12 ve 4.14) Extended Update Support (EUS) release olarak belirtir.

EUS release’lerinin, OpenShift Container Platform EUS aşamasına geçene kadar stable-4.x ve eus-4.x channel’ları (burada x, çift sayılı minor release belirtir) arasında hiçbir farkı yoktur. Kullanılabilir olduğu anda EUS channel’a geçilebilir.

 

1.2. Update Channel Support Durumu

Red Hat; fast, stable ve eus update channel’larında yayınlanan tüm update’ler için destek sunar. Red Hat, candidate channel’da yayınlanan update’leri yalnızca fast veya stable channel’larda da listelenmeleri durumunda destekler.

Resim: Update channels support durumu

 

1.3. Upgrade Paths

Upgrade channel’larının her birini farklı ortamlardaki Red Hat OpenShift Container Platform version 4.14 cluster’ına uygulayabilirsiniz. Aşağıda 4.14.3 sürümünün kusurlu olduğu örnek bir senaryo açıklanmaktadır.

Stable channel: Stable-4.14 channel’ını kullanırken cluster’ınızı 4.14.0'dan 4.14.1'e veya 4.14.2'ye upgrade edebilirsiniz. 4.14.3 release’inde bir sorun tespit edilirse o sürüme upgrade yapamazsınız. 4.14.4 release’inde bir patch kullanıma sunulduğunda ancak o zaman cluster’ınızı bu versiyona güncelleyebilirsiniz.

Bu channel, production ortamlarına uygundur, çünkü Red Hat SRE ekipleri ve destek hizmetleri bu channel’daki release’leri test eder.

Fast channel: fast 4.14 channel, 4.14.1 ve 4.14.2 update’lerini sunabilir ancak 4.14.3'ü sağlayamaz. Red Hat ayrıca bu channel’i desteklemektedir ve bunu development, QA veya production ortamlarına uygulayabilirsiniz.

Admin’lerin, yeni bir minor versiyondaki yeni bir release kullanılabilir olduğunda, buna upgrade yapmak için, özellikle fast-4.14 gibi farklı bir minor release channel seçmesi gerekir.

Resim: Web console üzerinde channel


Candidate channel:
OpenShift'in en yeni özelliklerini yüklemek için fast-4.14 channel kullanılabilir. Bu channel ile 4.14.1, 4.14.2 ve 4.14.3 gibi tüm z-stream release’lerine upgrade yapabilirsiniz.

Bu channel, ürünün en yeni özelliklerine yayınlandıklarında erişmek için kullanırsınız. Bu channel development ve pre-production ortamlara uygundur.

EUS channel: eus-4.14 channel’a geçiş yaparken, stable-4.14 channel, bir sonraki EUS versionu kullanıma sunulana kadar z-stream update’lerini almaz.

Resim: Stable ve Candidate channel için update grafikleri


Red Hat, stable ve fast channel’larda yayınlanan General Availability (GA) update’leri için destek sağlar. Red Hat, yalnızca candidate channel’da listelenen update’leri desteklemez.

Cluster’ın kararlılığını ve uygun support level’ı sağlamak için yalnızca stable channel bir channel’dan fast bir channel’a geçin. Stable veya fast bir channel’dan candidate channel’a geçiş mümkün olsa da önerilmez.

 

1.4. Update Process

Cluster update işlemlerinde aşağıdaki bileşenler bulunur. Tabi, update öncesinde etcd backup da dahil olmak üzere yapılandırma ve data backup’larının da alınmış olması önerilir.

Machine Config Operator: Machine Config Operator, istenen makine durumunu node’ların her birine uygular. Bu bileşen aynı zamanda cluster’daki node’ların rolling update şeklinde güncellenmesini de yönetir ve yapılandırma formatı olarak CoreOS Ignition'ı kullanır.

Operator Lifecycle Manager: OLM, cluster’daki herhangi bir operatörün update işlemlerini yönetir.

Cluster’ı web console ile veya komut satırından güncelleyebilirsiniz. Administration → Cluster Settings sayfası, yeni bir update mevcut olduğunda “available updates” seçeneğini görüntüler. Bu sayfadan “Select a version” 'a tıklayın ve ardından yüklemek istediğiniz versiyonu ve cluster update options seçeneğini seçin:

Resim: Web console yardımıyla cluster update


Update işlemi, update’ler kullanılabilir olduğunda temel işletim sistemini de günceller. Update’ler, transactional upgrade’leri yönetmek için rpm-ostree teknolojisini kullanır. Update’ler container image’lar aracılığıyla sunulur ve OpenShift update sürecinin bir parçasıdır. Update deploy edildiğinde, node’lar yeni imajı sırasıyla pull ve extract ederek paketleri diske yazar. Ardından yeni versiyon ile boot etmek için bootloader’ı değiştirir. Cluster kapasitesinin minimum düzeyde etkilenmesini sağlamak için makine yeniden başlatılır ve rolling update (birer birer) uygular.

Resim: Update tamamlandı


Update tamamlandığında yeni versiyonu web console veya cli üzerinden kontrol edebilirsiniz. Ardından cluster operatörler ve kendi uygulamalarınızın kontrolünü yapabilirsiniz.

 

2.    Linkler

https://console.redhat.com/openshift

https://docs.openshift.com/

https://docs.openshift.com/container-platform/4.14/updating/understanding_updates/intro-to-updates.html

https://access.redhat.com/labs/ocpupgradegraph/update_path/

 

Alpay Polat – Mayıs 2024

Güncel Blog Yazıları

2023'te Dijital Yatırımlarımızda Öne Çıkacak Konular
Turbonomic 101
Açık Kaynak Yazılım Lisans Türleri
INSTANA 101
Podman
GitLab 101
CI/CD Nedir?
GitLab’ın AI Yeteneği ve DevSecOps Platformundaki Rolü
Redis‘te En Sık Yapılan Hatalar
Bulut Teknolojisi Nedir?
Veritas ile Veri Yönetiminde Yenilikçi Yaklaşımlar
API Gateway'ler: Dijital Dönüşümde Verimliliği ve Güvenliği Artırmanın Yolu
Red Hat Ansible Lightspeed ve IBM Watsonx Code Assistant: BT Otomasyonunda Devrim
PostgreSQL’in Tarihçesi
PostgreSQL Mimarisi
Istio Service Mesh
Mikroservislerin Gelecegi
Elasticsearch Machine Learning
Gelişmiş Arama Deneyimi: Elasticsearch Relevance Engine ve Büyük Dil Modelleri ile Yapay Zeka Destekli Arama Çözümleri
Kubernetes - Cka Sınavı  Genel Başlıklar
Kubernetes Mimarisi
Openshift Updates
Dell OpenManage Enterprise ile Tek Yerden Çoklu Sistem Yönetimi
Dolandırıcılık Yönetim Sisteminin Önemi ve Bu Kapsamda Kullanılan ROC-Fraud Management System
Partner Settlements’ın Önemi ve Bu Kapsamda Kullanılan ROC-Partner Settlement System
Gelir Güvence Sisteminin Önemi ve Bu Kapsamda Kullanılan ROC-Revenue Assurance System
Windows Admin Center – Kolaylaştırılmış, Modern Uzaktan Sunucu Yönetim Aracı
Veri Tabanı Nedir? Veri Tabanı Güvenliğini Nasıl Sağlarız?
DevOps Nedir? DevOps Neden Önemlidir?
PostgreSQL’de TOAST (The Oversized-Attribute Storage Technique) Kavramı
MVCC (Multi Version Concurrency Control) nedir? PostgreSQL’in MVCC implementasyonu nasıldır?