OpenShift Container Platform Etcd Restore

1. Giriş

Konteyner tabanlı platformlar, mikroservis mimarilerinin yaygınlaşmasıyla birlikte modern BT altyapılarının temel bileşeni haline gelmiştir. Red Hat OpenShift, Kubernetes üzerine inşa edilmiş kurumsal bir platform olarak, uygulamaların yüksek erişilebilirlik, ölçeklenebilirlik ve operasyonel süreklilik gereksinimlerini karşılamayı hedefler.

Bu sürekliliğin sağlanmasında ETCD, OpenShift kontrol düzleminin en kritik bileşenlerinden biridir. Cluster içindeki tüm Kubernetes nesneleri, konfigürasyonlar ve durum bilgisi ETCD üzerinde saklanmaktadır. Dolayısıyla ETCD yedekleme ve geri yükleme mekanizmaları, felaket kurtarma (Disaster Recovery) stratejilerinin temelini oluşturmaktadır.

Bu yazıda, Red Hat OpenShift Container Platform (OCP) 4.18 sürümünde ETCD yedekleme (backup) ve geri yükleme (restore) süreçleri, uygulamalı bir senaryo üzerinden ele alınmıştır. Ayrıca; ETCD’nin Kubernetes nesnelerinin sürekliliğindeki kritik rolünü göstermek ve olası bir sistemsel veri kaybı senaryosunda kümenin nasıl tutarlı bir şekilde geri döndürülebileceği anlatılmıştır.

Etcd restore edilirken farklı yöntemler denenebilir;

Restoring to a previous cluster state for a single node: Backup, tek bir node üzerine restore edilir.
Restoring to a previous cluster state: HA yapıdaki cluster'da önceki duruma geri dönmek için, veya diğer master node’lar problemli ise bu yöntem kullanılabilir.
Restoring a cluster manually from an etcd backup: Restore işleminin manuel yapılması. UPI clusterlarda kullanılabilir, master node’lar problemli ise kullanılabilir.

Bu yazımızda manual yöntem kullanacağız.

2. ETCD Mimarisi ve OpenShift İçindeki Rolü

ETCD, dağıtık bir anahtar-değer (key-value) veri tabanı olup, Kubernetes API Server tarafından kullanılan birincil veri kaynağıdır. OpenShift mimarisinde ETCD bileşeni kontrol düzlemi (master) node’ları üzerinde çalışır.

ETCD, içerisinde barındırdığı verilerin replikasyonunu ve tutarlı kalmasını sağlar. Bu yapı, birden fazla master node’un bulunduğu yüksek erişilebilir cluster’larda veri bütünlüğünün korunmasına olanak tanır.

Şekil 1. OpenShift mimarisinde ETCD bileşeninin konumu

Openshift Container Platform içerisinde Etcd cluster, genellikle control plane node’ları içerisinde barındırılan podlar sayesinde çalışır.

Resim 1. Openshift Etcd Cluster

Openshift Container Platform; Etcd cluster yönetimini, önemli sistem altyapı bileşenlerinden olan, “etcd cluster operator” yardımıyla gerçekleştirir.

Resim 2. Openshift Etcd Cluster Operator

3. Test Senaryosu ve Uygulama

ETCD backup ve restore sürecini uygulamalı olarak gösterebilmek amacıyla bir test senaryosu tasarlanmıştır. Bu senaryoda basit ancak stateful özellikler içeren bir web uygulaması kullanılmıştır. Test ortamı olarak; 1 master node, 2 worker node’a sahip bir Openshift cluster kullanılmıştır. Uygulama nesnelerinin (deployment, service, route vb) silinmesi veya bozulması senaryosu olabileceği gibi, herhangi bir master node probleminde, küme kontrol düzlemi sunucularının çoğunu kaybettiğinde (quorum loss) veya bir admin, kritik bir nesneyi kazara sildiğinde de restore işlemine başvurulabilir.

Test senaryosunun bileşenleri aşağıda listelenmiştir:

Test işlemlerinin yapılabilmesi için kullanılan UPI yöntemle kurulmuş Openshift Container Platform v4.18,
“test-app” isimli OpenShift projesi (namespace),
“test-web1” uygulaması, HTTP Server (httpd) tabanlı bir Deployment,
Deployment’a bağlı bir Service,
Dış erişim için bir Route nesnesi,
/tmp dizinine mount edilen 2 GB boyutunda PersistentVolumeClaim (PVC)

PVC içerisine test amaçlı veri dosyaları oluşturulmuş ve bu dosyalar web pod’unun /tmp klasöründe tutulmaktadır. Bu sayede uygulamanın yalnızca stateless değil, aynı zamanda stateful davranış sergilediği gösterilmiştir.

Resim 3. “test-web1” Deployment

Resim 4. “test-app“ Proje Bileşenleri

Uygulamanın çalıştığını görmek için bir web browser ile bağlanmayı deniyoruz:

Resim 5. “test-web1“ Uygulaması Web Arayüzü

Senaryomuza göre, “test-app” projesindeki “test-web1” deployment’ını, buna bağlı “test-web1 (host=test-web1-test-app.apps.sng1.test.local)” adlı route nesnesini ve pod içerisinde bulunan /tmp klasöründeki bir kaç dosyayı sileceğiz. Uygulamanın çalışır durumda olup olmadığını kontrol edeceğiz, muhtemelen çalışmıyor olacak. Ardından projenin çalışır durumdayken alınan etcd backup’ı restore edip proje bileşenlerinin durumunu tekrar kontrol edeceğiz.

4. ETCD Backup Süreci

OpenShift 4.18 sürümünde ETCD yedekleme işlemi, Red Hat tarafından desteklenen ve kontrol düzlemi node’ları üzerinde çalışan etcd backup script’leri aracılığıyla gerçekleştirilmektedir.

Bu işlem sırasında ETCD veritabanının tutarlı bir snapshot’ı alınır. Snapshot, Kubernetes nesnelerinin tamamını ve cluster durumunu yedekleme anındaki haliyle içermektedir. Backup alınmadan önce, Cluster’da bir problem olmadığı, “healthy” durumda olması gerekmektedir.

Backup işlemi için bir control plane (master) node’a bağlanıp Red Hat’in bunun için sağladığı backup scriptini çalıştırıyoruz.

Resim 6. Etcd Backup

5. Arıza Senaryosu: Uygulamaya Ait Nesnelerin Silinmesi

ETCD yedeği alındıktan sonra test senaryosu kapsamında, uygulama pod’una bağlı PVC’den (/tmp) bazı dosyalar, “test-web1” Deployment’ı ve buna bağlı Route nesnesini manuel olarak siliyoruz.

Resim 7. Uygulamaya ait bazı nesnelerin silinmesi

Bu işlem sonucunda web uygulamasına yapılan HTTP isteklerinin başarısız olduğu ve uygulamanın erişilemez hale geldiği gözlemlenmiştir. Bu durum, Kubernetes nesnelerinin ETCD üzerinde tutulduğunu ve bu nesnelerin kaybının doğrudan servis kesintisine yol açtığını açıkça göstermektedir.

Resim 8. Uygulamada Hizmet Kesintisi

6. ETCD Restore Süreci ve Uygulama Testi

ETCD restore işlemi, daha önce alınmış olan snapshot kullanılarak cluster kontrol düzleminin geri yüklenmesi prensibine dayanır. Bu işlem sırasında ETCD verisi, backup alındığı zamandaki tutarlı duruma döndürülür.

Restore işleminin tamamlanmasının ardından OpenShift cluster’da Kubernetes API Server, ETCD üzerinde bulunan nesneleri tekrar yükler.

Bu senaryoda restore işlemi sonrasında, “test-web1” Deployment’ı ve buna bağlı Route nesnelerinin otomatik olarak geri geldiği ve uygulamanın yeniden erişilebilir olduğu doğrulanmıştır. Ancak, “Arıza Senaryosu” bölümünde sildiğimiz, PVC içerisinde tutulan 2 adet dosyanın geri gelmediği görülmektedir.

6.1. Etcd Restore İşlemi

Etcd restore işlemlerine başlarken aşağıdaki konulara dikkat edilmelidir:

İşlemler, cluster-admin rolünde bir kullanıcı ile yapılmalıdır.
Openshift Container Platform etcd restore yapılırken, önceden alınmış backup, mevcut Openshift z-stream sürümüyle aynı olmalıdır. Örneğin; önceki durumda küme versiyonu 4.18.2 ise son durumda da 4.18.2 olmalıdır.
Healthy durumdaki bir master'a ssh bağlantısı yapılabilmelidir.
Etcd snapshot ve static podlar için olan resource'ları da içeren backup dosyaları aynı klasörde olmalı, örneğin:
- /home/core/assets/backup
- "snapshot_.db" ve "static_kuberesources_.tar.gz"
Node'lar accessible ve bootable durumda olmalıdır.
Kurtarılabilir durumda olmayan master node'lar varsa onlara ssh yapmaya gerek yoktur. Restore sonrasında cluster'dan silinip sıfır kurulum ile cluster'a eklenebilirler.
Restore işlemi, “healthy” durumdaki bir master node’a ssh ile bağlanılıp, node içerisinden yapılmalıdır.
Diğer master'lara da farklı session'lardan ssh ile bağlanılmalıdır.
Restore sırasında apiserver erişilemez olacağı için "oc debug" gibi komutlar çalışmayabilir.
Backup dosyaları /home/core/ klasörüne kopyalanmalıdır.
Restore işleminin yapıldığı master node hariç, diğer master node’lardaki static podlar stop edilmelidir.

İşlemlere başlıyoruz:

[root@ocp-sng-cls ~]# ssh core@192.168.1.161

Red Hat Enterprise Linux CoreOS 418.94.202601071817-0

Part of OpenShift 4.18, RHCOS is a Kubernetes-native operating system

managed by the Machine Config Operator (`clusteroperator/machine-config`).

WARNING: Direct SSH access to machines is not recommended; instead,

make configuration changes via `machineconfig` objects:

https://docs.openshift.com/container-platform/4.18/architecture/architecture-rhcos.html

---

Last login: Thu Feb 5 07:21:14 2026 from 192.168.1.160

[core@ocp-single-m1 ~]$ sudo scp root@192.168.1.160:/tmp/snapshot_2026-02-09_091714.db /home/core/

root@192.168.1.160's password:

snapshot_2026-02-09_091714.db 100% 148MB 312.1MB/s 00:00

[core@ocp-single-m1 ~]$ sudo scp root@192.168.1.160:/tmp/static_kuberesources_2026-02-09_091714.tar.gz /home/core/

root@192.168.1.160's password:

static_kuberesources_2026-02-09_091714.tar.gz 100% 72KB 33.9MB/s 00:00

[core@ocp-single-m1 ~]$ ls -lh /home/core/

total 148M

drwxrwxrwx. 3 root root 20 Aug 25 09:58 assets

-rw-------. 1 root root 148M Feb 9 14:02 snapshot_2026-02-09_091714.db

-rw-------. 1 root root 72K Feb 9 14:02 static_kuberesources_2026-02-09_091714.tar.gz

# Etcd static podunu taşıyıp stop olmasını bekliyoruz (bir kaç dk sürebilir):

[core@ocp-single-m1 ~]$ sudo mv -v /etc/kubernetes/manifests/etcd-pod.yaml /tmp

copied '/etc/kubernetes/manifests/etcd-pod.yaml' -> '/tmp/etcd-pod.yaml'

removed '/etc/kubernetes/manifests/etcd-pod.yaml'

[core@ocp-single-m1 ~]$ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

# kube-apiserver static podunu taşıyıp stop olmasını bekliyoruz (bir kaç dk sürebilir):

[core@ocp-single-m1 ~]$ sudo mv -v /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp

copied '/etc/kubernetes/manifests/kube-apiserver-pod.yaml' -> '/tmp/kube-apiserver-pod.yaml'

removed '/etc/kubernetes/manifests/kube-apiserver-pod.yaml'

[core@ocp-single-m1 ~]$ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"

# kube-controller-manager static podunu taşıyıp stop olmasını bekliyoruz (bir kaç dk sürebilir):

[core@ocp-single-m1 ~]$ sudo mv -v /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /tmp

copied '/etc/kubernetes/manifests/kube-controller-manager-pod.yaml' -> '/tmp/kube-controller-manager-pod.yaml'

removed '/etc/kubernetes/manifests/kube-controller-manager-pod.yaml'

[core@ocp-single-m1 ~]$ sudo crictl ps | grep kube-controller-manager | egrep -v "operator|guard"

# kube-scheduler static podunu taşıyıp stop olmasını bekliyoruz (bir kaç dk sürebilir):

[core@ocp-single-m1 ~]$ sudo mv -v /etc/kubernetes/manifests/kube-scheduler-pod.yaml /tmp

copied '/etc/kubernetes/manifests/kube-scheduler-pod.yaml' -> '/tmp/kube-scheduler-pod.yaml'

removed '/etc/kubernetes/manifests/kube-scheduler-pod.yaml'

[core@ocp-single-m1 ~]$ sudo crictl ps | grep kube-scheduler | egrep -v "operator|guard"

# Her master node'da "etcd" datasını farklı klasöre taşı:

[core@ocp-single-m1 ~]$ sudo mkdir /home/core/assets/old-member-data # Tüm node'larda çalıştırıyoruz...

[core@ocp-single-m1 ~]$ sudo mv /var/lib/etcd/member /home/core/assets/old-member-data # Tüm node'larda çalıştırıyoruz...

# Her bir master node için doğru etcd name parametresini bul:

[core@ocp-single-m1 ~]$ sudo cat $RESTORE_ETCD_POD_YAML | grep -A 1 $(sudo cat $RESTORE_ETCD_POD_YAML | grep 'export ETCD_NAME' | grep -Eo 'NODE_.+_ETCD_NAME') | grep -Po '(?<=value: ").+(?=")'

ocp-single-m1.test.local

xxx

yyy

# değeri, master node'da şu komutla oluşturulabilir

# (Sadece 1 kez oluşturulmalıdır, diğer master'larda oluşturulmamalıdır, hepsi bunu kullanacak):

[core@ocp-single-m1 ~]$ uuidgen

17aa56ae-b503-47fe-b39b-76a54dd3eb05

# Değeri için doğru IP aşağıdaki komutla öğrenilebilir:

# değerini yukarıda bulmuştuk (ocp-single-m1.test.local):

[core@ocp-single-m1 ~]$ sudo su

[root@ocp-single-m1 ~]$ ETCD_NAME=ocp-single-m1.test.local

[root@ocp-single-m1 ~]$ echo $ETCD_NAME |

sed -E 's/[.-]/_/g' |

xargs -I {} grep {} /etc/kubernetes/static-pod-resources/etcd-certs/configmaps/etcd-scripts/etcd.env |

grep "IP" | grep -Po '(?<=").+(?=")'

192.168.1.161 # Doğru IP: 192.168.1.161...

[root@ocp-single-m1 ~]$ ETCD_NODE_PEER_URL=https://192.168.1.161:2380 && echo $ETCD_NODE_PEER_URL

https://192.168.1.161:2380

# Backup dosyasını kopyalıyoruz:

[root@ocp-single-m1 core]# cp /var/home/core/snapshot_2026-02-09_091714.db /var/lib/etcd/

# Doğru etcdctl imajını belirliyoruz:

[root@ocp-single-m1 core]# jq -r '.spec.containers[]|select(.name=="etcdctl")|.image' /tmp/etcd-pod.yaml

quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:0d7c52702a3541e76f9cd38b1eb5b8ae3380253735572357bd873916c3172e66

[root@ocp-single-m1 core]# podman run --rm -it --entrypoint="/bin/bash" -v /var/lib/etcd:/var/lib/etcd:z quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:0d7c52702a3541e76f9cd38b1eb5b8ae3380253735572357bd873916c3172e66

[root@0c9d8241b18c /]# etcdctl version

etcdctl version: 3.5.18

API version: 3.5

[root@0c9d8241b18c /]#

# Parametre değerlerinin set edilmesi:

[root@0c9d8241b18c /]# ETCD_NAME=ocp-single-m1.test.local # Diğer master'larda çalıştırırken o master etcd name yazılır...

[root@0c9d8241b18c /]# ETCD_INITIAL_CLUSTER="ocp-single-m1.test.local=https://192.168.1.161:2380" # 3 master'lı kümelerde 3 master da virgül ile ayrılarak yazılmalıdır...

[root@0c9d8241b18c /]# UUID=17aa56ae-b503-47fe-b39b-76a54dd3eb05 # 3 master'lı kümelerde bu kısım aynı kalmalıdır.

[root@0c9d8241b18c /]# ETCD_NODE_PEER_URL=https://192.168.1.161:2380 # Diğer master'larda çalıştırırken o master url'i yazılır...

# Restore işlemini başlatıyoruz (aynı container içerisinde iken):

[root@0c9d8241b18c /]# ETCDCTL_API=3 /usr/bin/etcdctl snapshot restore /var/lib/etcd/snapshot_2026-02-09_091714.db

--name "$ETCD_NAME"

--initial-cluster="$ETCD_INITIAL_CLUSTER"

--initial-cluster-token "openshift-etcd-$UUID"

--initial-advertise-peer-urls "$ETCD_NODE_PEER_URL"

--data-dir="/var/lib/etcd/restore-$UUID"

--skip-hash-check=true

Deprecated: Use `etcdutl snapshot restore` instead.

2026-02-09T16:02:06Z info snapshot/v3_snapshot.go:265 restoring snapshot {"path": "/var/lib/etcd/snapshot_2026-02-09_091714.db", "wal-dir": "/var/lib/etcd/restore-17aa56ae-b503-47fe-b39b-76a54dd3eb05/member/wal", "data-dir": "/var/lib/etcd/restore-17aa56ae-b503-47fe-b39b-76a54dd3eb05", "snap-dir": "/var/lib/etcd/restore-17aa56ae-b503-47fe-b39b-76a54dd3eb05/member/snap", "initial-memory-map-size": 0}

2026-02-09T16:02:06Z info membership/store.go:141 Trimming membership information from the backend...

2026-02-09T16:02:06Z info membership/cluster.go:421 added member {"cluster-id": "568e17cef86e9fdc", "local-member-id": "0", "added-peer-id": "78484e71979de040", "added-peer-peer-urls": ["https://192.168.1.161:2380"], "added-peer-is-learner": false}

2026-02-09T16:02:06Z info snapshot/v3_snapshot.go:293 restored snapshot {"path": "/var/lib/etcd/snapshot_2026-02-09_091714.db", "wal-dir": "/var/lib/etcd/restore-17aa56ae-b503-47fe-b39b-76a54dd3eb05/member/wal", "data-dir": "/var/lib/etcd/restore-17aa56ae-b503-47fe-b39b-76a54dd3eb05", "snap-dir": "/var/lib/etcd/restore-17aa56ae-b503-47fe-b39b-76a54dd3eb05/member/snap", "initial-memory-map-size": 0}

[root@298ad4e9e6bb /]# exit

# Diğer master node'larda da bu işlemler tekrar edilir...

# Yeni oluşturulan etcd database'ini default yerine taşıyıp diğer işlemleri yapıyoruz:

# mv /var/lib/etcd/restore-/member /var/lib/etcd

[root@ocp-single-m1 core]# mv /var/lib/etcd/restore-17aa56ae-b503-47fe-b39b-76a54dd3eb05/member/ /var/lib/etcd/

[root@ocp-single-m1 core]# restorecon -vR /var/lib/etcd/

[root@ocp-single-m1 core]# rm -rf /var/lib/etcd/restore-17aa56ae-b503-47fe-b39b-76a54dd3eb05/

[root@ocp-single-m1 core]# rm /var/lib/etcd/snapshot_2026-02-09_091714.db

# Bu dosya taşıma/silme işlemleri diğer master'larda da yapılır.

# Etcd kümesini restart ediyoruz:

[root@ocp-single-m1 core]# mv /tmp/etcd-pod.yaml /etc/kubernetes/manifests

[root@ocp-single-m1 core]# crictl ps | grep etcd | grep -v operator

ea31410ecca4c 87a16e2d2c1048723628454a70f7dafe638c7b5ba476d1357aa27932733cc3e8 10 minutes ago Running etcd-rev 0 ce0d5e02db01a etcd-ocp-single-m1.test.local

33d80c895a17c 87a16e2d2c1048723628454a70f7dafe638c7b5ba476d1357aa27932733cc3e8 10 minutes ago Running etcd-readyz 0 ce0d5e02db01a etcd-ocp-single-m1.test.local

36d0baacf29ec 93273fb016a59656f0a076545cdc6fba3bc39507e5609eb3d72afaa1443f87d8 10 minutes ago Running etcd-metrics 0 ce0d5e02db01a etcd-ocp-single-m1.test.local

a0e72b15d2a4b 93273fb016a59656f0a076545cdc6fba3bc39507e5609eb3d72afaa1443f87d8 10 minutes ago Running etcd 0 ce0d5e02db01a etcd-ocp-single-m1.test.local

be1367724b519 93273fb016a59656f0a076545cdc6fba3bc39507e5609eb3d72afaa1443f87d8 10 minutes ago Running etcdctl 0 ce0d5e02db01a etcd-ocp-single-m1.test.local

[root@ocp-single-m1 core]# crictl exec -it $(crictl ps | grep etcdctl | awk '{print $1}') etcdctl endpoint status -w table

+----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

+----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

| https://192.168.1.161:2379 | 78484e71979de040 | 3.5.18 | 155 MB | true | false | 2 | 13 | 13 | |

+----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

# Diğer static podları restart ediyoruz, tüm master'larda ama teker teker,

# Örneğin; kube-apiserver bir masterda çalışınca diğer master'dakini çalıştırıyoruz:

[root@ocp-single-m1 core]# mv /tmp/kube-apiserver-pod.yaml /etc/kubernetes/manifests/

[root@ocp-single-m1 core]# crictl ps | grep kube-apiserver | grep -v operator

c240c4c7df6bd 7953399075eee5915471c134e4fef74cbde93332a69a2b7b07176b0aab85a467 55 seconds ago Running kube-apiserver-check-endpoints 0 a7b7735b4cdfb kube-apiserver-ocp-single-m1.test.local

22e2775341e90 7953399075eee5915471c134e4fef74cbde93332a69a2b7b07176b0aab85a467 56 seconds ago Running kube-apiserver-insecure-readyz 0 a7b7735b4cdfb kube-apiserver-ocp-single-m1.test.local

619ca21f25a88 7953399075eee5915471c134e4fef74cbde93332a69a2b7b07176b0aab85a467 56 seconds ago Running kube-apiserver-cert-regeneration-controller 0 a7b7735b4cdfb kube-apiserver-ocp-single-m1.test.local

fa4bc9db61a9f 7953399075eee5915471c134e4fef74cbde93332a69a2b7b07176b0aab85a467 56 seconds ago Running kube-apiserver-cert-syncer 0 a7b7735b4cdfb kube-apiserver-ocp-single-m1.test.local

8770fd3d42749 25e2c04bd18fd6bfba6cbcc07bac725b75ba4ba25ef8fad998b294961c8f3c1c 56 seconds ago Running kube-apiserver 0 a7b7735b4cdfb kube-apiserver-ocp-single-m1.test.local

[root@ocp-single-m1 core]# mv /tmp/kube-controller-manager-pod.yaml /etc/kubernetes/manifests/

[root@ocp-single-m1 core]# crictl ps | grep kube-controller | grep -v operator

6c12f955e7401 97fb6d3bc998de1a317e0e1a4d65a0e4c0c47f59b6b2ce764d084d10c471cf88 31 seconds ago Running kube-controller-manager-recovery-controller 0 de733b179dea7 kube-controller-manager-ocp-single-m1.test.local

94c024c404995 97fb6d3bc998de1a317e0e1a4d65a0e4c0c47f59b6b2ce764d084d10c471cf88 31 seconds ago Running kube-controller-manager-cert-syncer 0 de733b179dea7 kube-controller-manager-ocp-single-m1.test.local

6c4ac8f2c5588 182e3eaca39ee43f4e7d72793427c8c8a4902cefc89096047c0e3c2d80eb7f98 31 seconds ago Running cluster-policy-controller 0 de733b179dea7 kube-controller-manager-ocp-single-m1.test.local

6ba5a83e964fe 25e2c04bd18fd6bfba6cbcc07bac725b75ba4ba25ef8fad998b294961c8f3c1c 31 seconds ago Running kube-controller-manager 0 de733b179dea7 kube-controller-manager-ocp-single-m1.test.local

243ac7c048bb4 5dceef78e03ef14602c94cddbd9fe527f0ac914c58d721e01444a4ed635225f1 10 hours ago Running ovnkube-controller 10 557c8a595817a ovnkube-node-7f5tw

[root@ocp-single-m1 core]# mv /tmp/kube-scheduler-pod.yaml /etc/kubernetes/manifests/

[root@ocp-single-m1 core]# crictl ps | grep kube-scheduler | grep -v operator

6b63284a291c1 2a2fdef7d12571a471761b9af0829a33e9e813c2b57edfb6d31450ad157d2fbd 21 seconds ago Running kube-scheduler-recovery-controller 0 bbe88aba92857 openshift-kube-scheduler-ocp-single-m1.test.local

555f63c32161c 2a2fdef7d12571a471761b9af0829a33e9e813c2b57edfb6d31450ad157d2fbd 21 seconds ago Running kube-scheduler-cert-syncer 0 bbe88aba92857 openshift-kube-scheduler-ocp-single-m1.test.local

2bbd89235f0e5 25e2c04bd18fd6bfba6cbcc07bac725b75ba4ba25ef8fad998b294961c8f3c1c 22 seconds ago Running kube-scheduler 0 bbe88aba92857 openshift-kube-scheduler-ocp-single-m1.test.local

# OVN Database'ini wipe ediyoruz (işlemler uzun sürüyor):

[root@ocp-single-m1 core]# exit

[core@ocp-single-m1 ~]$ exit

logout

$ for NODE in $(oc get node -o name | sed 's:node/::g'); do oc debug node/${NODE} -- chroot /host /bin/bash -c 'rm -f /var/lib/ovn-ic/etc/ovn*.db && systemctl restart ovs-vswitchd ovsdb-server'; oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-node --field-selector=spec.nodeName=${NODE} --wait; oc -n openshift-ovn-kubernetes wait pod -l app=ovnkube-node --field-selector=spec.nodeName=${NODE} --for condition=ContainersReady --timeout=600s; done

Starting pod/ocp-single-m1testlocal-debug-gk88l ...

To use host binaries, run `chroot /host`

Removing debug pod ...

pod "ovnkube-node-7f5tw" deleted

pod/ovnkube-node-8x92c condition met

Starting pod/ocp-single-w1testlocal-debug-gk5fl ....

To use host binaries, run `chroot /host`

...

6.2. Uygulama Testi

Bu aşamada, Openshift kümemize yeniden Cli ve Web UI üzerinden login olup testleri yapabiliriz. "test-app" projesinde sildiğimiz "test-web1" deployment'ı ve "test-web1" route nesnelerini kontrol ediyoruz ve restore sonrasında geri geldiklerini görüyoruz:

[root@ocp-sng-cls ~]# oc project test-app

Now using project "test-app" on server "https://api.sng1.test.local:6443".

[root@ocp-sng-cls ~]# oc get deployment

NAME READY UP-TO-DATE AVAILABLE AGE

test-web1 1/1 1 1 11h

[root@ocp-sng-cls ~]# oc get route

NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD

test-web1 test-web1-test-app.apps.sng1.test.local test-web1 8080 None

Web browser üzerinden uygulama çalışmıyordu, onu tekrar test ediyoruz ve çalışır durumda olduğunu görüyoruz:

Resim 8. Uygulama Testi – HTTP Server çalışıyor

Etcd restore öncesinde, “test-web1” Deployment’a ait “test-web1-pvc1” adlı PVC’de /tmp klasöründen “test-file6.txt” ve “test-file7.txt” dosyalarını silmiştik. Etcd restore sonrasında, PVC yedeklemesi etcd backup kapsamında olmadığından, silinen dosyaların geri gelmediği görülmüştür. PVC içeriklerinin ilgili yedekleme ürünleri ile yedeklenmesi gerekmektedir.

Resim 9. PVC içindeki dosyalar

7. Sonuç ve Değerlendirme

Bu çalışma kapsamında, OpenShift 4.18 ortamında ETCD backup ve restore mekanizmasının, Kubernetes nesnelerinin korunması ve felaket kurtarma senaryolarındaki kritik rolü uygulamalı olarak gösterilmiştir. Ancak, etcd backup işlemi, PVC’ler içerisinde tutulan dosyaları yedeklemediğinden, “Arıza Senaryosu” bölümünde sildiğimiz 2 adet dosyanın geri gelmediği görülmektedir. PVC’lerde tutulan verilerin yedeklenmesi, etcd backup kapsamı dışındadır ve onlar ayrıca yedeklenmelidir.

Uyarı: Etcd restore işlemi, çalışan bir küme için yıkıcı ve tutarsızlıklara sebep olabilen bir işlemdir. Bu işlemler, özellikle production ortamları için, yalnızca son çare olarak kullanılmalıdır.

Sonuç olarak, ETCD yedeklerinin düzenli aralıklarla alınması, yedeklerin güvenli ortamlarda saklanması ve restore prosedürlerinin periyodik olarak gözden geçirilmesi, kurumsal OpenShift ortamları için temel bir operasyonel gerekliliktir.