Video summary
Bu video eğitimi, Red Hat OpenShift Service Mesh'in (OSSM) sürüm 2'den sürüme geçiş sürecini detaylı bir şekilde ele almaktadır ve bu yükseltmenin hem mimari hem de operasyonel açıdan getirdiği önemli iyileştirmeleri vurgulamaktadır. Sürüm 3, geleneksel merkezi kontrol düzlemini ve zorunlu yan taraflı enjeksiyon yapısını terk ederek, kaynak tüketimini optimize etmek için node seviyesindeki jet tünelini ve Kubernetes Gateway API'sini kullanan ayrık olmayan (sidecarless) ambient mimarisine geçişi sağlamaktadır. Bu dönüşüm sırasında cluster ortamının en azından OSSM 2.6.14 sürümü veya üzerinded olması ve altta yatan OpenShift Container Platform'ın da 4.16 veya daha yeni bir versiyona yükseltilmiş olması gibi temel ön koşulların sağlanması gerekmektedir; ayrıca geçiş süreci ilk olarak ana sürüme odaklanmalı, ardından spesifik küçük sürüm güncellemeleri gerçekleştirilmelidir.
Göç öncesi hazırlık aşamasında en kritik adım, otomatik route takibinin kaldırılması nedeniyle kaynak çakışmalarını önlemek ve yolların manuel yönetimine geçiş sağlamaktır. Bu süreçte gateway kontrolünün yerelleştirilmesi ve otomatik ağ politikası yönetimlerinin devre dışı bırakılması hayati önem taşımaktadır. Cluster'ı güvenli bir şekilde hazırlamak için SMCP temel manifesti düzenlenerek Grafana, Kiali ve Prometheus gibi varsayılan login eklentileri kapatılırken, ağ politikası işleme parametreleri false konumuna getirilir. Giriş mimarisi de bu süreçte yerel bir kaymaya uğrar; gateway'ler artık global olarak değil, doğrudan ilgili uygulama namespace'i içinde yeniden dağıtılmakta ve dışarıya erişim sağlamak amacıyla manuel oluşturulan OpenShift route kullanılarak sanal servis özel kaynakları (custom resource) içine açıkça haritalandırılır.
Sürüm 3'te kontrol düzlemi sales operator tarafından yönetilirken, en son Istio CNI ve seçici etiketler sayesinde izleme ve yönetim sadece service mesh işlevliliği gerektiren belirli namespace'lere sınırlanır. İş yükü entegrasyonu ise revision tabanlı bir modelle gerçekleştirilerek eski ve yeni kontrol düzleminin cluster üzerinde güvenli şekilde birlikte var olmasını sağlar; bu yaklaşım, sürüm iki operatörünün zarifçe silinmesine izin verirken minimum duruş süresiyle namespace bazlı aşamalı geçişleri mümkün kılar. Canlı gösterimde mevcut ortam doğrulanmış, legacy bileşenler devre dışı bırakılmış ve gateway'lerin uygulama projeleri içine yerleştirilmesi sağlanmıştır; ardından OSM 3 operator hub'dan kurulmuş, yeni Istio CNI ve kontrol düzlemi başarıyla başlatılarak iş yüklerinin güncellenmiş mimariye güvenli bir şekilde bağlanması için rolling restart işlemi uygulanmıştır.
Son aşamada ise tüm OSSM 2 kaynakları temizlenerek geçiş tamamlanmaktadır; bu süreç SSMR, legacy service mesh operator aboneliği ve ilgili diğer kaynakların cluster'dan kaldırılması ile eski CRD'lerin silinmesini içerir. Bu adımlar tamamlandığında cluster meta verileri tamamen temizlenmiş olur ve uygulama trafiğinin kesintisiz bir şekilde yeni Red Hat OpenShift Service Mesh 3 altyapısı üzerinden yönlendirildiği doğrulanır. Böylece, minimal duruş süresiyle birlikte modernize edilmiş ve optimize edilmiş service mesh ortamına başarıyla geçiş sağlanmış olunur.
Read the full video transcript
Hello everyone, welcome to this video
tutorial of OpenShift Service Mesh
migration from version 2 to version 3.
I'm Durgesh Banja working as a support
engineer in Red Hat OpenShift networking
team.
Through this tutorial, we will explore
the essential steps for successful
migration beginning with the fundamental
differences between the two versions and
reviewing core prerequisites. Next, we
will review a pre-migration checklist
and conclude with a live demonstration
of gateway and workload migration.
The introduction of OpenShift Service
Mesh 3 bring significant architectural
and operational improvements, making
this upgrade highly beneficial. While
OSM 2 rely on the traditional
centralized control plane with mandatory
sidecar injection across all port.
OSM 3 introduce a decoupled sidecarless
ambient architecture using node-level
jet tunnels and Kubernetes Gateway API
to optimize resource consumptions.
Here are some prerequisite that one
should keep in the mind before
initializing this upgrade. The cluster
environment must be at least on OSM
version 2.6.14 or higher and underlying
OpenShift container platform must be
upgraded to version 4.16 or later. The
upgrade should first target OSM 3.0
while the upgrades to specific minor
release can be carried out afterward.
The pre-migration checklist focus on
mitigating resource conflict because
automatic route tracking is dropped in
version 3. Team must explicitly
transition to manually manage route.
Furthermore, gateway control must be
localized and automatic network policy
management must be disabled.
To safely prepare the cluster, a simple
legacy SMCP state is established by
modifying the SMCP basic manifest. The
administrator disables default login
add-ons like Grafana, Kiali, and
Prometheus while toggling the network
policy handling parameters to false.
The ingress architecture undergoes a
localized shift during the migration
process. Gateway are redeployed directly
within the specific application
namespace.
External ingress exposure is
reestablished using manually exposed
OpenShift route, which are then
explicitly mapped inside a virtual
service custom resource.
In OpenShift Service Mesh 3, the control
plane is managed by sale operator. It
uses the latest Istio CNI and discuss
selectors to limit the monitoring and
management to only the labeled namespace
that require the service mesh
functionality.
Finally, workload onboarding is achieved
using revision based onboarding. This
level model allows both old and new
control plane to coexist safely on the
cluster. This allows for a
phase-by-phase namespace transition with
a minimal downtime before the version
two operator is gracefully deleted.
Let's begin the live demonstration by
verifying the existing environment.
Here, as we can see in Istio system
project, the Istiod and other respective
pods are running fine. The SMCP is ready
and SSMR is configured correctly.
With the route, the control plane and
member roles are actively managing the
bookinfo namespace, which serves as our
demo application.
The sample application pods are running
fine in the bookinfo project.
To ensure the application is running and
fully accessible, a continuous request
loop is started against the active
routing path.
The Kiali monitoring console confirms
that application traffic is flowing
normally [clears throat] through the
legacy service mesh.
Now, let's prepare the cluster for
migration by removing the legacy
component that conflict with version
three at runtime.
The configuration file is modified to
systematically turn off default login
add-ons, internal gateways, and
automated routing rules.
Note that the automatic network policy
management is disabled to prevent a
firewall conflict during the transition.
As the changes save, the legacy operator
terminates the centralized services
leaving behind only single minimal
control plane pod.
Next step is to decentralize the ingress
framework.
While gateway can be deployed globally
in the Istio system namespace,
in this scenario, we will deploy the
instance directly inside the application
project.
To make this gateway accessible from the
outside world, an external route is
manually generated.
The new routing path is then updated
inside the service mesh configuration
file by explicitly editing the gateway
and virtual service resources
to safely allowing and redirecting user
traffic line to the application.
Next, install OSM 3 from operator hub.
This process may take few minutes, so we
will wait for the installation to
complete before moving to the next step.
After the operator installation is
complete, the new Istio CNI component is
deployed, followed by the Istiod control
plane, establishing a new revision-based
service mesh instance.
Once both component reach to ready
state, the application namespace is
labeled with the appropriate revision to
connect it to the version three control
plane.
Finally, a rolling restart of a
application pod is performed allowing
the workloads to reconnect and securely
attach to the updated service mesh
architecture.
The process concludes with the clean up
of legacy and homing.
All remaining OSM 2 resources, including
SSMR, legacy service mesh operator
subscription, and associated resources
are then removed from the cluster.
Followed by the removal of old CRDs to
fully clean up the cluster metadata.
Once this clean up finished, the
migration is completed and the
application traffic continues to be
routed seamlessly through the new Red
Hat OpenShift Service Mesh 3 with the
minimal downtime.
Thank you.