Openshift’de Uygulamanın Kesintisiz Çalışmasını Sağlama
Openshift’de çalışan Blockchain uygulamamızın kesintisiz çalışmasını sağlamak için aldığım bazı tedbirleri burada paylaşmak istedim. Bu tedbirleri aşağıdaki gibi üç başlık altında toparladım;
· Replicaset
· Pod Affinity
· Horizontal Pod Autoscaler
Replicaset
Uygulama pod olarak ayağa kaldırılırken ihtiyaç duyulan tanımlamalar Deployment objesi ile yapılır. Uygulamanızı kaç adet pod üzerine dağıtmak istediğiniz, kullanacağınız imaj, çalışma esnasında ne kadar CPU ve memory’nin Openshift’den talep edileceği gibi konuları deployment objesinin içerisinde tariflersiniz. Deployment objesi ile ilgili detaylı bilgiyi bu linkten alabilirsiniz.
Aşağıdaki deployment’da, web-backend podunun replica sayısı 2 olarak girdim. Bu sayede podlardan herhangi birinde sorun olduğunda diğer podun istekleri karşılaması ile uygulamanın kesintisizliği sağlamaya çalıştım. Genelde minimum pod sayısını 2 olarak ayarlamaya özen gösterdim.
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: web-backend
name: web-backend
spec:
replicas: 2
selector:
matchLabels:
app: web-backend
strategy:
type: Recreate
template:
metadata:
labels:
app: web-backend$ oc get po
NAME READY STATUS RESTARTS AGE
web-backend-5f7bc5665b-8q7xv 1/1 Running 0 12s
web-backend-5f7bc5665b-gcq7r 1/1 Running 0 10s$ oc get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
web-backend 2/2 2 2 6m27sYukarıda çalıştırdığım oc get po ve oc get deployment komutları ile pod sayısı ve replica bilgilerini görebilirsiniz.
Pod Affinity
Pod affinity ve pod anti-affinity podların node’lara nasıl yerleştirilmesi gerektiğini tanımlamak için kullanılır. Deployment yaml’ınızda yaptığınız pod affinity tanımı ile aynı node üzerinde çalışmasını istediğiniz podları bir arada toparlayabilirsiniz. Aynı şekilde, anti-affinity tanımı ile podlarınızı farklı node’lara dağıtabilirsiniz. Örneğin replicaset’lerinizi ayrı node’lar üzerine dağıtarak herhangi bir node’daki sorundan uygulamanızın etkilenmeyip, kesintisiz çalışmasını sağlayabilirsiniz.
Pod affinity ve anti-affinity tanımı yapmadığınız zaman podlarınız node’lardaki CPU ve memory uygunluğuna göre rastgele dağıtılır, aynı node’da da olabilir, farklı node’da da.
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: web-backend
name: web-backend
spec:
replicas: 2
selector:
matchLabels:
app: web-backend
strategy:
type: Recreate
template:
metadata:
labels:
app: web-backend
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web-backend
topologyKey: "kubernetes.io/hostname"Web-backend podlarını farkı node’lara dağıtmak için yaml’da spec alanı altına affinity.podAntiAffinity tanımını girdim. Affinity ve Anti-affinity’nin de iki tür kuralı var bunlar;
requiredDuringSchedulingIgnoredDuringExecution
preferredDuringSchedulingIgnoredDuringExecution
requiredDuringSchedulingIgnoredDuringExecution tanımı girildiğinde, podların node üzerinde planlanması için gerekli kuralların karşılanması gerekir. Hard affinity olarak da geçer.
preferredDuringSchedulingIgnoredDuringExecution tanımı girildiğinde podların node üzerinde planlanması için gerekli kuralların karşılanması garanti edilmez. Soft affinity olarak da geçer.
Kuralın uygulanması için, labelSelector tanımı altında key ve value(label) çiftinin eşleşmesi beklenir. In, NotIn, Exists veya DoesNotExist logic operator olarak kullanılır. Benim tanımladığım kural, web-backend label’ına sahip olan podların farklı node’lara dağıtılması şeklindedir.
oc get po -o wide komutu çıktısında podların farklı node’lara dağıtıldığı görülmektedir.
oc get po -o wide
NAME READY STATUS RESTARTS AGE NODE
web-backend-5f7bc5665b-8q7xv 1/1 Running 0 39s worker-jn2ww
web-backend-6785d46767-mr8mz 1/1 Running 0 39s worker-kn9rc Podları aynı node’da bir araya getirmek istersek, deployment yaml’ınıza affinity.podAffinity tanımını girmelisiniz.
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: web-backend
name: web-backend
spec:
replicas: 2
selector:
matchLabels:
app: web-backend
strategy:
type: Recreate
template:
metadata:
labels:
app: web-backend
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web-backend
topologyKey: "kubernetes.io/hostname"$ oc get po -o wide
NAME READY STATUS RESTARTS AGE NODE
web-backend-6785d46767-4l526 1/1 Running 0 25s worker-jn2ww
web-backend-6785d46767-bbr68 1/1 Running 0 25s worker-jn2wwHorizontal Pod AutoScaler
Horizontal Pod Autoscaler (HPA), podlardan toplanan CPU ve Memory metriklerine göre pod sayısını otomatik olarak arttırır veya azaltır. HPA tanımını deployment, deployment config, replica set, veya stateful set’lerinize yapabilirsiniz.
HPA tanımlamalarını Openshift web konsolundan yapabilirsiniz. HPA eklemek istediğiniz Deployment’ın detayına gittiğinizde sağ üst köşedeki Actions listesinden Add HorizontalPodAutoScaler seçilir.
Eğer deployment’ınızda CPU ve memory limiti tanımlı değilse aşağıdaki uyarı karşınıza çıkacaktır. CPU ve memory limiti tanımlanmadıkça HPA metrikleri okuyamayacaktır. Kaynak limitleri ile ilgili detay bilgiye bu linkten ulaşabilirsiniz.
Deployment’ınızın Openshift’den talep edeceği cpu-memory limitini ayarlamak için yine Actions listesinden Edit Resource Limits formu açılır, podunuzun Openshift’den talep edeceği minimum ve maksimum kaynak değerleri girilir.
Daha sonra yine Actions listesinden Add HorizontalPodAutoScaler seçilir. Form view ya da YAML view’dan CPU veya Memory limitleri yüzde olarak ne kadar aşıldığında pod sayısını kaça çıkarmak istediğinizi girebilirsiniz. Örnekte, CPU değeri %10'u geçtiğinde pod sayısını 3'e arttır, %10 altına indiğinde pod sayısını tekrar 2'ye çek tanımını yaptım.
oc get hpa komutu çıktısı, 2 replicalı web-backend podunun şu an total CPU tüketiminin %2 olduğunu, replica sayısının artması için %10 değerini geçmesi gerektiğini göstermektedir.
$ oc get po
NAME READY STATUS RESTARTS AGE
web-backend-58f77cf759-pk6s5 1/1 Running 0 13m
web-backend-58f77cf759-szhfk 1/1 Running 0 13m$ oc get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
web-backend Deployment/web-backend 2%/10% 2 3 2 20moc describe hpa komutu ile hpa detayına baktığımızda yüksüz durum aşağıdaki gibidir.
$ oc describe hpa web-backend
Name: web-backend
Namespace: test-asli
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 03 Oct 2023 14:32:26 +0300
Reference: Deployment/web-backend
Metrics: ( current / target )
resource cpu on pods (as a percentage of request): 1% (1m) / 10%
Min replicas: 2
Max replicas: 3
Deployment pods: 2 current / 2 desired
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ScaleDownStabilized recent recommendations were higher than current one, applying the highest recent recommendation
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
Gelelim yük testine …
Yük testi için Apache Bench (ab) kullandım. Ab ile yük testlerini komut satırından yapıp, sonuçları da komut satırından görebiliriz. Kurulumu, kullanımı basit ve hızlı. Ab kurulumunu buradan yapabilirsiniz .
Aşağıdaki komutu çalıştırdığımızda, 1000 adet isteği aynı anda 10 kullanıcı ile uygulamamızın adresine gönderiyoruz.
ab -n 1000 -c 10 -r http://web-backend.test.com.tr/
Ab çıktısının detayına girmedim. Openshift web rayüzünden podumun CPU metriğine baktığımda, yük testi ile birlikte tüketimin arttığını gözlemledim. Aşağıdaki grafiği biraz büyütürseniz, yeşil renkli podun bir süre sonra devreye girdiğini görebilirsiniz.
CLI komutları ile de pod arttırımını teyit ettim. %10 olarak konulan CPU değeri %31'e çıktıktan bir süre sonra replica sayısı 3 olarak güncellendi.
$ oc get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
web-backend Deployment/web-backend 31%/10% 2 3 2 20m
$ oc get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
web-backend Deployment/web-backend 31%/10% 2 3 3 20m
$ oc get po
NAME READY STATUS RESTARTS AGE
web-backend-58f77cf759-hczjx 1/1 Running 0 65s
web-backend-58f77cf759-pk6s5 1/1 Running 0 20m
web-backend-58f77cf759-szhfk 1/1 Running 0 20mHpa’nın detayına baktığımızda yük geldiğinde replica sayısının 3' çıktığını, yük ortadan kalktıktan bir süre sonra tekrar 2 replicaya indiğini görebiliriz.
Name: web-backend
Namespace: test-asli
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 03 Oct 2023 14:40:26 +0300
Reference: Deployment/web-backend
Metrics: ( current / target )
resource cpu on pods (as a percentage of request): 4% (4m) / 10%
Min replicas: 2
Max replicas: 3
Deployment pods: 2 current / 2 desired
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale recommended size matches current size
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited True TooFewReplicas the desired replica count is less than the minimum replica count
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 33m horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 27m horizontal-pod-autoscaler New size: 2; reason: All metrics below targeTekrar oc get po komutu ile podları listelediğimde pod sayısının 2'ye düştüğünü görebiliriz.
$ oc get po
NAME READY STATUS RESTARTS AGE
web-backend-58f77cf759-pk6s5 1/1 Running 0 23m
web-backend-58f77cf759-szhfk 1/1 Running 0 23mKendimce aldığım tedbirleri şimdilik bu şekilde özetleyebilirim. Autoscaling konusunda daha da detaya inilebilir. Referanslarda paylaştığım Redhat dokümanına bakarsanız, yüke göre soft bir geçişle kademe kademe pod arttırım ve azaltımının nasıl yapılacağını görebilirsiniz.
Gelecek yazılarda görüşmek dileğiyle, kendinize iyi bakın, sağlıcakla kalın😊
Referanslar
Ford Otosan — Dijital Ürünler ve Servisler
Teknoloji ve Kurumsal Mimari Servis Liderliği — Teknoloji İnovasyonu Takım Üyesi
Aslıhan Cura Uray
