In this article, you will learn about:

• Reasons why Pods get evicted: Preemption and Node Pressure
• How Preemption eviction works
• Understanding Pod Priority Classes
• Node Pressure eviction explained
• Exploring Quality of Service (QoS) Classes
• How the Kubernetes Descheduler helps manage evictions
• Common Descheduler strategies for improving cluster balance
• When and why you might want to use the Descheduler in your cluster
• How to install and usage Descheduler

What is Evicted Pods in Kubernetes ?

In Kubernetes, when a Pod is evicted, it means the Pod is forcibly terminated, often because the cluster is running low on critical resources such as memory or CPU. But what leads to this situation?

Eviction is a process where a Pod running on a Node is asked to terminate. One of the most common cases in Kubernetes is preemption, where a Pod needs to be evicted to make room for a new Pod when the Node doesn’t have enough available resources.

Reasons why Pods get evicted: Preemption and Node Pressure

In Kubernetes, Pods are evicted primarily for two reasons: preemption and node pressure. Preemption happens when a higher-priority Pod needs to be scheduled, but there aren’t enough available resources on any node — forcing the system to evict lower-priority Pods to make room. Node pressure eviction occurs when a node runs critically low on essential resources like memory, CPU, or disk space, and Kubernetes needs to terminate some Pods to maintain node stability and prevent failure.

How Preemption eviction works

Preemption is the process where the Kubernetes scheduler evicts existing Pods to make room for a higher-priority Pod. When a Node doesn’t have enough available resources and the new Pod has a higher priority than the ones already running, the scheduler terminates lower-priority Pods to free up space. This mechanism ensures that critical applications are not blocked by less important workloads.

Understanding Pod Priority Classes

Pod Priority Classes are used in Kubernetes to assign priority levels to Pods.
These classes help determine which Pods should stay running and which should be evicted when the cluster experiences resource shortages.
Pods with higher priority are scheduled before lower-priority ones and are better protected when resources become scarce. This system ensures that critical applications remain operational even under resource constraints.

Below you can see two examples of Priority Class:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority-emirhan
value: 1000000
preemptionPolicy: PreemptLowerPriority
globalDefault: false
description: "This priority class is for important workloads."
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: low-priority-emirhan
value: 50000
preemptionPolicy: PreemptLowerPriority
globalDefault: false
description: "This priority class is for less critical workloads."

Below you can see the pod sample where two examples of priority classes are used:

apiVersion: v1
kind: Pod
metadata:
  name: high-priority-pod
spec:
  priorityClassName: high-priority
  containers:
  - name: nginx
    image: nginx
---
apiVersion: v1
kind: Pod
metadata:
  name: low-priority-pod
spec:
  priorityClassName: low-priority
  containers:
  - name: nginx
    image: nginx

If the node experiences resource pressure, the low-priority Pod will be evicted while the high-priority Pod will continue running, as Kubernetes uses the preemption mechanism to make room for higher-priority Pods.

Node Pressure eviction explained

Node pressure eviction happens when a Node starts running out of critical resources like memory, CPU, or disk space.
To prevent the Node from crashing, Kubernetes selects and evicts certain Pods, usually starting with lower-priority or lower-quality (QoS) Pods.
This automatic mechanism helps maintain cluster health and balances resource usage across the Nodes.

Exploring Quality of Service (QoS) Classes

In Kubernetes, Quality of Service (QoS) classes categorize Pods based on their resource requests and limits.
There are three main QoS classes: Guaranteed, Burstable, and BestEffort.

• Guaranteed Pods specify both requests and limits for their resources and receive the highest level of protection.
• Burstable Pods have partial protection, with some resource limits defined but not fully guaranteed.
• BestEffort Pods do not specify any resource guarantees and have the lowest priority.
  When a node faces resource pressure, Kubernetes evicts BestEffort Pods first, followed by Burstable Pods, and only as a last resort, Guaranteed Pods.

How the Kubernetes Descheduler helps manage evictions

The Kubernetes scheduler places Pods across the cluster based on available resources and policies. However, over time, the cluster’s conditions change— new Pods are added, old ones are removed, and resource usage can become unbalanced. This is where the Descheduler comes into play.
The Descheduler evaluates the current state and can recommend or perform the eviction and rescheduling of Pods to more appropriate Nodes. By doing so, it helps reduce node pressure, improves load balancing, and ensures that high-priority Pods have a better environment to run. In short, the Descheduler keeps the cluster healthy by making smarter use of available resources over time.

Common Descheduler strategies for improving cluster balance

The Descheduler uses several strategies to optimize resource usage and maintain balance across the cluster.
Some of the most common strategies include:

• RemovePodsViolatingInterPodAntiAffinity: Reschedules Pods that violate inter-pod anti-affinity rules.
• RemovePodsViolatingNodeAffinity: Moves Pods that do not comply with node affinity constraints to appropriate nodes.
• RemovePodsViolatingTopologySpreadConstraint: Ensures Pods are evenly distributed across nodes according to topology spread constraints.
• LowNodeUtilization: Evicts Pods from underutilized nodes and redistributes them to achieve better resource utilization. These strategies help reduce node pressure, improve load distribution, and enhance the overall performance and stability of the cluster.
• HighNodeUtilization: Targets nodes that are heavily overutilized and evicts Pods to relieve resource pressure. By redistributing Pods to less busy nodes, this strategy improves overall cluster balance and prevents performance degradation on overloaded nodes.

When and why you might want to use the Descheduler in your cluster

While the Kubernetes scheduler does a good job placing Pods initially, over time the balance of the cluster can drift. As new Pods are deployed, resource usage changes, or some Pods behave unpredictably, certain Nodes may become overloaded while others remain underutilized. This imbalance can impact cluster efficiency and application performance. You might want to use the Descheduler to:

• Rebalance resource usage across Nodes,
• Proactively redistribute Pods before node pressure becomes critical,
• Move Pods that violate affinity or taint rules,
• Improve overall cluster health and scalability.
  The Descheduler is especially valuable in production environments where clusters run for long periods and workloads constantly evolve.

How to install and usage Descheduler

$ helm repo add descheduler https://kubernetes-sigs.github.io/descheduler/
$ helm repo update

Below are our values.yaml :

kind: Deployment #1

schedule: "" #2

deschedulingInterval: 60s #3
replicas: 3 #4
leaderElection: #5
  enabled: true 
deschedulerPolicy:
  strategies: #6
    LowNodeUtilization:
      enabled: true
      params:
        thresholds:
          cpu: 20
          memory: 20
        targetThresholds: #7
          cpu: 50
          memory: 50

1. Tells Helm to deploy the Descheduler as a long-running Deployment, not as a CronJob that wakes up on a schedule.
2. Empty string disables the CronJob template entirely (it only matters when kind is CronJob). Setting it to "" guarantees no CronJob is rendered.
3. Inside the Deployment, the Descheduler binary reruns itself every 60 seconds to check cluster state and evict pods if needed.
4. Creates three Descheduler pods for high availability. Only one will actively evict; the others wait on standby.
5. With multiple replicas, this switch makes them elect a leader so that only one pod performs evictions at any moment.
6. Enables the LowNodeUtilization strategy, which looks for nodes that are over- or under-used and moves pods away from over-loaded ones.
7. These are the “upper” limits. If a node’s CPU or memory usage rises above 50 %, it’s considered busy and pods can be evicted from it. The very high pods: 500 effectively says ignore pod count; just use CPU/memory.

$ helm install descheduler descheduler/descheduler --version 0.31.0 -n descheduler --create-namespace -f deschedulerdeployment.yaml

Below are our helm’s output:

let’s check our descheduler pods:

The current pod status is shown below:

kubectl get pods -o wide
NAME                          READY   STATUS    RESTARTS      AGE     IP            NODE                     NOMINATED NODE   READINESS GATES
nginx-deploy-96b9d695-722xd   1/1     Running   3 (12h ago)   27d     10.244.2.4    k8s-playground-worker    <none>           <none>
nginx-deploy-96b9d695-8vffd   1/1     Running   3 (12h ago)   27d     10.244.1.14   k8s-playground-worker2   <none>           <none>
nginx-deploy-96b9d695-98phx   1/1     Running   0             2m14s   10.244.1.17   k8s-playground-worker2   <none>           <none>
nginx-deploy-96b9d695-q2fcp   1/1     Running   0             2m14s   10.244.2.15   k8s-playground-worker    <none>           <none>
nginx-deploy-96b9d695-rrkct   1/1     Running   3 (12h ago)   27d     10.244.1.9    k8s-playground-worker2   <none>           <none>

Below is the YAML file we use for the CPU stress test:

apiVersion: v1
kind: Pod
metadata:
  name: cpu-stress
spec:
  nodeName: k8s-playground-worker      
  containers:
  - name: stress
    image: polinux/stress-ng
    command: ["/bin/sh","-c"]
    args: ["stress-ng --cpu 16--timeout 300s"]
    resources:
      requests:
        cpu: "9000m"
      limits:
        cpu: "9000m"
  restartPolicy: Never

$ kubectl apply -f cpustresspod.yaml

Below is the output from one of the Descheduler pods:

I0619 18:18:51.783561       1 lownodeutilization.go:150] "Number of overutilized nodes" totalNumber=1
I0619 18:18:51.783605       1 nodeutilization.go:261] "Total capacity to be moved" CPU=10450 Mem=1433800704 Pods=84
I0619 18:18:51.783639       1 nodeutilization.go:264] "Evicting pods from node" node="k8s-playground-worker" usage={"cpu":"10100m","memory":"562Mi","pods":"14"}
I0619 18:18:51.783719       1 nodeutilization.go:267] "Pods on node" node="k8s-playground-worker" allPods=14 nonRemovablePods=5 removablePods=9
I0619 18:18:51.783743       1 nodeutilization.go:274] "Evicting pods based on priority, if they have same priority, they'll be evicted based on QoS tiers"
I0619 18:18:51.902877       1 evictions.go:186] "Evicted pod" pod="default/nginx-deploy-96b9d695-972w9" reason="" strategy="LowNodeUtilization" node="k8s-playground-worker" profile="default
"
I0619 18:18:51.907219       1 nodeutilization.go:325] "Evicted pods" pod="default/nginx-deploy-96b9d695-972w9"
I0619 18:18:51.907992       1 nodeutilization.go:350] "Updated node usage" node="k8s-playground-worker" CPU=10100 Mem=589299712 Pods=13
I0619 18:18:52.011975       1 evictions.go:186] "Evicted pod" pod="test/redis-748ffbc5f5-l9kbh" reason="" strategy="LowNodeUtilization" node="k8s-playground-worker" profile="default"
I0619 18:18:52.018723       1 nodeutilization.go:325] "Evicted pods" pod="test/redis-748ffbc5f5-l9kbh"
I0619 18:18:52.020331       1 nodeutilization.go:350] "Updated node usage" node="k8s-playground-worker" CPU=10100 Mem=589299712 Pods=12
I0619 18:18:52.145416       1 evictions.go:186] "Evicted pod" pod="test/redis-748ffbc5f5-w424w" reason="" strategy="LowNodeUtilization" node="k8s-playground-worker" profile="default"
I0619 18:18:52.145570       1 nodeutilization.go:325] "Evicted pods" pod="test/redis-748ffbc5f5-w424w"
I0619 18:18:52.150791       1 nodeutilization.go:350] "Updated node usage" node="k8s-playground-worker" CPU=10100 Mem=589299712 Pods=11
I0619 18:18:52.271926       1 evictions.go:186] "Evicted pod" pod="test/redis-748ffbc5f5-z9fxh" reason="" strategy="LowNodeUtilization" node="k8s-playground-worker" profile="default"
I0619 18:18:52.271970       1 nodeutilization.go:325] "Evicted pods" pod="test/redis-748ffbc5f5-z9fxh"
I0619 18:18:52.271984       1 nodeutilization.go:350] "Updated node usage" node="k8s-playground-worker" CPU=10100 Mem=589299712 Pods=10
I0619 18:18:52.404432       1 evictions.go:186] "Evicted pod" pod="default/nginx-deploy-96b9d695-rphhb" reason="" strategy="LowNodeUtilization" node="k8s-playground-worker" profile="default
"
I0619 18:18:52.404502       1 nodeutilization.go:325] "Evicted pods" pod="default/nginx-deploy-96b9d695-rphhb"
I0619 18:18:52.404519       1 nodeutilization.go:350] "Updated node usage" node="k8s-playground-worker" CPU=10100 Mem=589299712 Pods=9
I0619 18:18:52.505450       1 evictions.go:186] "Evicted pod" pod="test/redis-748ffbc5f5-96skg" reason="" strategy="LowNodeUtilization" node="k8s-playground-worker" profile="default"
I0619 18:18:52.509694       1 nodeutilization.go:325] "Evicted pods" pod="test/redis-748ffbc5f5-96skg"
I0619 18:18:52.510311       1 nodeutilization.go:350] "Updated node usage" node="k8s-playground-worker" CPU=10100 Mem=589299712 Pods=8
I0619 18:18:52.625005       1 evictions.go:186] "Evicted pod" pod="test/redis-748ffbc5f5-9k6vc" reason="" strategy="LowNodeUtilization" node="k8s-playground-worker" profile="default"
I0619 18:18:52.625092       1 nodeutilization.go:325] "Evicted pods" pod="test/redis-748ffbc5f5-9k6vc"
I0619 18:18:52.625110       1 nodeutilization.go:350] "Updated node usage" node="k8s-playground-worker" CPU=10100 Mem=589299712 Pods=7
I0619 18:18:52.724450       1 evictions.go:186] "Evicted pod" pod="test/redis-748ffbc5f5-x5qm9" reason="" strategy="LowNodeUtilization" node="k8s-playground-worker" profile="default"
I0619 18:18:52.724505       1 nodeutilization.go:325] "Evicted pods" pod="test/redis-748ffbc5f5-x5qm9"
I0619 18:18:52.724521       1 nodeutilization.go:350] "Updated node usage" node="k8s-playground-worker" CPU=10100 Mem=589299712 Pods=6
I0619 18:18:52.846428       1 evictions.go:186] "Evicted pod" pod="test/redis-748ffbc5f5-2m5kt" reason="" strategy="LowNodeUtilization" node="k8s-playground-worker" profile="default"
I0619 18:18:52.854322       1 nodeutilization.go:325] "Evicted pods" pod="test/redis-748ffbc5f5-2m5kt"
I0619 18:18:52.854410       1 nodeutilization.go:350] "Updated node usage" node="k8s-playground-worker" CPU=10100 Mem=589299712 Pods=5
I0619 18:18:52.854462       1 profile.go:345] "Total number of pods evicted" extension point="Balance" evictedPods=9
I0619 18:18:52.854494       1 descheduler.go:179] "Number of evicted pods" totalEvicted=11

The official documentation provides various usage examples for different Strategy Plugins, which will not be repeated here.

Sources I benefited from:

Scheduling, Preemption and Eviction | Kubernetes

Understanding Kubernetes Evicted Pods | Sysdig

Node-pressure Eviction | Kubernetes

Thank you for reading until the end. Before you go:

Please remember to clap for this article and follow me! 👏 If you want to follow me, LinkedIn

Understanding Pod Eviction and How to Use the Kubernetes Descheduler was originally published in folksdev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Turkcell WEB/APP uygulamasındaki monolitik backend yapılarımızı mikroservis mimarisine dönüştürürken, servisler arasındaki iletişimi iyileştirmek ve süreci daha verimli hale getirmek için farklı araçlar üzerinde çalışmalar yaptık. Bu süreç bizi gRPC’ye yönlendirdi ve özellikle yapısı gereği sunduğu ayrıcalıklar süreçlerimiz için bir çok avantaj sağladığını fark ettik. Bu süreçte edindiğim deneyimler ve bilgilere birlikte göz atalım.

Neden İhtiyaç Duyuldu?

Öncelikle gRPC’ye tam bir giriş yapmadan önce, neden böyle bir ihtiyaç doğduğunu ele alalım.

gRPC’ye olan ihtiyacı anlamak için yukarıdaki gibi bir uygulamanın mikroservis dönüşüm sürecindeki iletişim problemini inceleyelim.

Monolitik mimaride geliştirilen uygulamalar, ihtiyaç doğrultusunda mikroservis mimarisine geçiş yapılmaktadır. Bu geçiş sürecinde, uygulamada bir bütün olarak çalışan servisler, birbirinden bağımsız olarak ihtiyaca göre parçalanır. Ancak, bu parçalanma sonrasında servislerin ihtiyaç halinde birbiriyle iletişim kurması gerekir ve bu noktada ek bir maliyet oluşur.

Monolitik mimaride servisler arası iletişim doğrudan gerçekleşirken, mikroservislerde servislerin birbiriyle iletişim kurması için genellikle HTTP tabanlı Restful API’ler kullanılır. Ancak, Restful API’ler metin tabanlı mesajlar (JSON/XML) ağır veri formatları kullandığından, her istek için header bilgilerinin taşınması performans açısından önemli bir yük oluşturabilir.

gRPC ise bu tür maliyetleri ortadan kaldırarak, monolitik mimariye en yakın şekilde hızlı ve verimli bir iletişim sunar. Restful gibi yöntemlerden farklı olarak, binary veri formatları kullanması ve HTTP/2 protokolü üzerinden çalışması sayesinde performans avantajı sağlar.

Bu nedenlerden dolayı gRPC, mikroservisler arası iletişimde hız, düşük gecikme ve daha az ağ yükü gibi önemli farklar yaratmaktadır. Şimdi, gRPC’nin bu avantajlarını daha yakından inceleyelim.

gRPC Nedir?

Google tarafından geliştirilmiş, açık kaynaklı Remote Procedure Call(RPC) kütüphanesidir. RPC, uzak sunucudaki methodları sanki kendi ortamının birer parçasıymış gibi çalıştırabilen sistemlerdir.

Ana amacı client ve server arasında yüksek, güvenilir ve verimli bir iletişim sağlamaktır. Özellikle mikroservis mimarisinde servisler arasında yüksek hızda iletişim sağlar. RESTful sistemlere göre metin tabanlı veri formatları yerine, binary tabanlı veri formatı kullanır.

gRPC, veriyi serilize ve deserilize etmek için Protocal Buffers adlı bir veri tanımlama dili (Interface Defination Language) kullanır.

Protobuf, verileri küçük ve hızlı bir şekilde kodlamak için tasarlanmıştır. gRPC’nin performansının büyük kısmı, Protobuf’un sağladığı bu hızlı ve az yer kaplayan serileştirme yeteneklerinden gelir. Bu da ağ üzerindeki yükü azaltır ve işlem sürelerini hızlandırır.

gRPC Avantajları:

• Yüksek performans ve verimlilik: gRPC, HTTP/2 protokolü üzerinden binary tabanlı bir iletişim sağlayarak, yüksek performanslı ve düşük geçikmeli bir iletişim sağlar.
• Streaming yeteneği: gRPC, tek seferlik request/response dışında çift yönlü bir iletişim yeteneğine sahiptir.
• Güçlü tip güvenliği ve sözleşmeler: Protobuf ile tanımlanan arayüzler sayesinde sıkı bir tip güvenliği sağlar ve client ile server arasındaki servisler net olarak belirlenir.
• Çapraz platform ve dil desteği: Birçok platform ve dil desteğine sahiptir. Örneğin client tarafı Java iken server tarafı C++ veya Python olabilir.

Protocoll Buffers

Protobuf, mesajların ve servislerin tanımlarının yapıldığı bir IDL (Interface Definition Language)’dir. Yazılan proto dosyası, servis ve mesajların oluşturulması için kod üretiminde yardımcı olur. Böylece verileri serialize ve deserialize ederek, binary veri formatını rahatlıkla kullanmamızı sağlar.

Yukarıda bir proto dosyasını inceleyelim.

Öncelikle, Protobuf’un farklı sürümleri kullanılmakta ve sürekli gelişmektedir. Proto3, en son sürüm olduğu için bu örnekte onu kullanıyoruz.

Kod üretiminde, sınıfların hangi paket altında üretileceğini belirtmek için ise package bilgisi doldurulmalıdır.

Örneğimize baktığımızda, servis ve mesaj tanımlarının yapıldığını görüyoruz. Mesajlarda kullanılan numaralar, serileştirme sırasında hangi alanın hangi veriye karşılık geldiğini belirtmek için oldukça önemlidir.

Bu örnekte ise, bir kullanıcının fatura detaylarını alabilmesi için gerekli servis ve mesaj tanımlarını proto dosyasıyla nasıl yazdığımızı görebiliriz. Gelin bu proto için gRPC client ve gRPC server nasıl oluşturabileceğimizi inceleyelim.

gRPC Server

Proto dosyası derlendiğinde, BillingServiceGrpc.BillingServiceImplBase sınıfı oluşturulur. Bu sınıf, proto dosyasında tanımlanan servis için bir isteğin sonucunu döndürebileceğimiz metot sunar.

Proto dosyası ise bizim arayüzümüz olarak işlev görür. Orada tanımlanan her metodu override ederek, servis yanıtını istediğimiz gibi oluşturabiliriz.

gRPC Client

Öncelikle, bir gRPC client istek göndermek istediği gRPC server bağlantı kurması gerekir. gRPC server’in çalıştığı adres bilgisi yml dosyasında aşağıdaki gibi tanımlanır.

Bu şekilde, gRPC client’ın ihtiyaç duyduğu bağlantı adresi tanımlanmış olur. Ardından proto dosyası derlendiğinde üretilen BillingServiceGrpc sınıfına, bu adres bilgisi sağlanarak client ile server arasında bağlantı kurulmuş olur.

Burada önemli olan diğer bir bilgi ise, buradaki isteğimiz unary olduğu için BillingServiceGrpc.BillingServiceBlockingStub client’ını kullanıyoruz. Örneğin, isteğimiz server-side streaming iletişim modelinde olsaydı, BillingServiceGrpc.BillingServiceStub client’ını kullanabilirdik.

gRPC farklı iletişim yöntemlerini destekler, gelin birlikte bunlara göz atalım.

gRPC İletişim Türleri

gRPC client ve server arasında farklı iletişim modellerini destekler. gRPC’yi verimli şekilde kullanmak istiyorsak, ihtiyacımıza uygun iletişim modelini seçmek oldukça önemlidir.

Unary RPC

Geleneksel request/response isteklerine benzer. Client, tek bir istek için server’dan tek bir yanıt alır. Örnek verecek olursak, REST API’lerimiz unary RPC modeline benzer.

Server Streaming RPC

Bu iletişim modelinde client server’a bir istek gönderir ve server birden fazla mesajını akış gönderir. Örneğin, bir video veya müzik dosyası client tarafından talep edildiğinde, server medya içeriğini parça parça client’a iletir.

Client Streaming RPC

Buradaki modelde ise client tarafından bir streaming isteği başlatılır, tüm istekler iletildiğinde server tüm isteklere karşı bir response döner. Örneğin, bir dosyayı parçalar halinde client tarafından gönderebiliriz ve tüm parçalar gönderildiğinde server, yüklemenin sonucu hakkında bir response döner.

Bidirectional Streaming RPC

Son olarak bu iletişim modelinde client ve server arasında birbirlerinden bağımsız olarak bir streaming söz konusudur. İletişim her iki yönde de eş zamanlı olarak gerçekleşir. Örnek verecek olursak, yolda giden bir aracın server’a durumu hakkında veriler yolladığı ve server’ın ilettiği trafik bilgileri hakkında sürekli ve eş zamanlı bir akış olarak gerçekleşmesi olabilir.

gRPC vs Rest

gRPC ve RESTfull arasında bir çok farklılıklar vardır, bunlardan bazılarını aşağıdaki görselden inceleyebilirsiniz.

Bu yazımda genel olarak gRPC kapsamlı bir şekilde anlatmaya çalıştım. Bir sonraki gRPC yazımda, exception handling, rate limiting, monitor and logging gibi konuları gRPC sürecinde nasıl uygulayabiliriz konularını ele almaya çalışacağım. Bir sonraki yazıda görüşmek dileğiyle, sağlıcakla kalın :)

gRPC: Yüksek Performanslı İletişim Kütüphanesi was originally published in folksdev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Merhaba! Bugün sizlere, Plotly kullanarak oluşturduğunuz grafiklerin nasıl statik hale getirilebileceğini ve bu grafiklerin nasıl online olarak paylaşılabileceğini anlatacağım. Bu sayede projelerinizi ve analizlerinizi daha geniş kitlelerle kolayca paylaşabilirsiniz.

Rapor oluştururken daha statik grafiklere ihtiyaç duyabiliriz ve bu grafiklerin sadece yerel bilgisayarımızda kalmasını tercih etmeyebiliriz. Bu durumda, grafiklerinizi herkesin erişimine açmak için kullanabileceğiniz pratik bir çözüm var: Plotly Chart Studio.

Adımlar

1️⃣ Plotly Chart Studio Hesabı Oluşturma

• Plotly Chart Studio web sitesine gidin.
• Bir hesap oluşturun veya mevcut Plotly hesabınızla giriş yapın.

2️⃣ Plotly Kütüphanelerini Yükleme

Plotly ve Chart Studio kütüphanelerini yüklemek için aşağıdaki komutu kullanın:

pip install plotly chart-studio

3️⃣ Plotly Credentials Ayarlama

• API key ve kullanıcı adınızı ayarlamanız gerekiyor. Bu bilgileri Plotly hesap ayarlarınızdan bulabilirsiniz.
• chart-studio modülünü kullanarak ayarları yapın

import chart_studio
import chart_studio.plotly as py
import chart_studio.tools as tls

username = 'YOUR_USERNAME'  # Plotly kullanıcı adınız
api_key = 'YOUR_API_KEY'    # Plotly API anahtarınız
chart_studio.tools.set_credentials_file(username=username, api_key=api_key)

4️⃣ Grafiği Plotly Chart Studio’ya Yükleme

import pandas as pd
import plotly.express as px

# Basit bir veri kümesi oluşturma
data = {
    'Gün': ['Pazartesi', 'Salı', 'Çarşamba', 'Perşembe', 'Cuma'],
    'Değer': [10, 15, 13, 17, 14]
}
df = pd.DataFrame(data)

# Çizgi Grafik oluşturma
fig = px.line(df, x='Gün', y='Değer', title='Haftalık Değerler',
              labels={'Gün': 'Günler', 'Değer': 'Değerler'},
              color_discrete_sequence=['#1f77b4'])

# Grafik tasarımını düzenleme
fig.update_layout(
    plot_bgcolor='white',
    title_font=dict(family="Roboto Mono", size=24, color='#000000'),
    font=dict(family="Roboto Mono", size=16, color='#000000'),
    xaxis_tickfont=dict(family="Roboto Mono", size=14, color='#000000'),
    yaxis_tickfont=dict(family="Roboto Mono", size=14, color='#000000'),
    showlegend=False
)

# Grafiği Plotly Chart Studio'ya yükleme
py.plot(fig, filename='haftalik_degerler_linechart', auto_open=True)

Avantajlar

• Kullanım Kolaylığı: Plotly Chart Studio, grafiklerinizi hızlı ve kolay bir şekilde paylaşmanızı sağlar.
• Profesyonellik: Grafiğiniz Plotly’nin kendi sunucularında barındırılır, bu da profesyonel ve güvenilir bir çözüm sunar.
• Interaktivite: Grafikler interaktif olarak paylaşılabilir, böylece kullanıcılar grafiklerle etkileşime girebilir.

Bu adımları takip ederek, Plotly ile oluşturduğunuz grafiklerinizi kolayca online hale getirebilir ve paylaşabilirsiniz. Bu sayede projeleriniz ve analizleriniz daha geniş kitlelere ulaşacak ve daha etkili olacak.

Okuduğunuz için teşekkür ederim. ✍️(◔◡◔)

Plotly ile Oluşturulan Grafiklerin Statik ve Paylaşılabilir Hale Getirilmesi was originally published in folksdev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Modern yazılım sistemlerinde, özellikle mikroservis mimarilerinde, geçici hatalar (örneğin, ağ bağlantı sorunları veya geçici hizmet kesintileri) sıklıkla karşılaşılan durumlardır. Bu tür geçici hataları yönetmek ve uygulamanızın güvenilirliğini artırmak için yeniden deneme (retry) mekanizmaları kullanılır. Spring Retry, bu tür mekanizmaları Spring uygulamalarında kolayca uygulamak için tasarlanmış güçlü bir kütüphanedir. Ayrıca, Spring Retry’nin `Recover` işlevi, tüm denemeler başarısız olduğunda uygulamanızın nasıl tepki vereceğini belirlemenize olanak tanır.

Spring Retry ve Recover Nedir?

Spring Retry
Spring Retry, belirli bir işlem başarısız olduğunda, bu işlemi otomatik olarak belirli sayıda tekrar denemenize olanak tanır. Örneğin, bir veritabanı bağlantısı kurmaya çalıştığınızda bir hata alırsanız, Spring Retry bu bağlantı denemesini otomatik olarak tekrar eder. Böylece, geçici hatalarla başa çıkabilir ve işlemlerin başarılı olma olasılığını artırabilirsiniz.

Spring Recover
Spring Recover ise tüm yeniden deneme girişimleri başarısız olduğunda devreye giren bir mekanizmadır. Recover işlevi, hata durumlarında alternatif bir işlem veya hata yönetimi stratejisi sunar. Bu, uygulamanızın beklenmeyen durumlarla daha zarif bir şekilde başa çıkmasını sağlar.

Spring Retry kullanarak bir proje geliştirelim

Projemizi oluşturmak için ilk adım olarak projemizin ihtiyaç duyduğu bağımlılıkları ekleyerek başlayalım. Bu kapsamda Spring Web, Spring Retry , Spring Aop ve Lombok bağımlılıklarını projemize eklememiz gerekiyor.

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-web</artifactId>
  </dependency>

  <dependency>
   <groupId>org.springframework.retry</groupId>
   <artifactId>spring-retry</artifactId>
  </dependency>

  <dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-aop</artifactId>
  </dependency>

  <dependency>
   <groupId>org.projectlombok</groupId>
   <artifactId>lombok</artifactId>
   <optional>true</optional>
  </dependency>

Config için fazla şeye ihtiyacımız yok, sadece Application class’ına @EnableRetry eklememiz yeterli.

@EnableRetry: Bu işaretleme Spring’in metotları yeniden deneme desteğini etkinleştirmek için kullanılır.

Metot Açıklamaları

`retryOrderProcess` -> Bu metot, sipariş detayları boş ise `SQLException` fırlatır. Eğer `SQLException` meydana gelirse, metot üç kez yeniden denenir. Üç başarısız denemeden sonra, `recoverOrderProcess` metodu devreye girer ve bir kurtarma işlemi yapar.

`retryOrderProcessWithBackoff` -> Bu metot da, sipariş detayları boş ise `SQLException` fırlatır. `SQLException` durumunda, metot maksimum beş kez yeniden denenir. Her yeniden denemede bekleme süresi başlangıçta 2 saniye olup, her seferinde iki katına çıkarılacak şekilde artar. Maksimum bekleme süresi 30 saniyedir. Beş başarısız denemeden sonra, `recoverOrderProcessWithBackoff` metodu devreye girer ve bir kurtarma işlemi yapar.

Request ve Log Çıktıları

@Retryable Anotasyonu: Parametrelerin Detaylı Açıklaması

1. `value` veya `retryFor`
Bu parametre, hangi istisnalar karşısında yeniden deneme yapılacağını belirtir. Bir exception sınıfı veya exception sınıfı dizisi kabul eder.

@Retryable(value = { SQLException.class, IOException.class })

2. `exclude` veya `noRetryFor`
Bu parametre, yeniden deneme yapılmayacak exception’ı belirtir. Bu exception karşısında yeniden deneme yapılmaz.

@Retryable(exclude = { IllegalArgumentException.class, NullPointerException.class })

3. `maxAttempts`
Yeniden deneme girişimlerinin maksimum sayısını belirtir. Varsayılan değer 3'tür.

@Retryable(maxAttempts = 5)

4. `backoff`
Yeniden denemeler arasındaki bekleme süresini yapılandırmak için kullanılır. `@Backoff` anotasyonu ile birlikte kullanılır.

@Retryable(backoff = @Backoff(delay = 2000, multiplier = 2))

`@Backoff` Anotasyonunun Parametreleri:
- `delay`: İlk yeniden deneme öncesinde bekleme süresini (milisaniye cinsinden) belirtir.
- `multiplier`: Her başarısız denemeden sonra bekleme süresinin çarpanını belirtir.

1. deneme: delay = 2000 ms
2. deneme: delay = 2000 * 2 = 4000 ms
3. deneme: delay = 4000 * 2 = 8000 ms
...

- `maxDelay`: Bekleme süresinin maksimum değerini belirtir.
- `random`: Yeniden denemeler arasında rastgele bir gecikme ekler.

5. `recover`
Yeniden deneme girişimlerinin hepsi başarısız olursa çağrılacak metodun adını belirtir. Bu metod, hataları ele almak için bir geri kazanım mekanizması sağlar.

@Retryable(recover = "recoverOrderProcess")

6. `label`
Bu parametre, yeniden deneme işlemine bir etiket ekler. Bu etiket, özellikle loglama ve izleme gibi durumlar için yararlıdır.

@Retryable(label = "orderRetry")

Öne Çıkan Özellikler ve Faydalar

• Dayanıklılık ve Güvenilirlik: Geçici hatalar karşısında işlemlerinizi tekrar deneyerek başarı şansını artırır ve sisteminizin güvenilirliğini sağlar.
• Esneklik: Yeniden deneme stratejilerini kolayca özelleştirebilir, farklı gecikme süreleri ve deneme sayıları belirleyebilirsiniz.
• Hata Yönetimi: Recover işlevi ile, tüm yeniden denemeler başarısız olsa bile uygulamanızın belirli bir şekilde tepki vermesini sağlayarak, hata yönetimini optimize edebilirsiniz.
• Kod Temizliği: Karmaşık hata yönetim kodlarını azaltır ve kodunuzu daha temiz ve yönetilebilir hale getirir.

Projenin kaynak kodlarına buradan ulaşabilirsiniz.

GitHub - mgmetehan/spring-retry-recover

Sonuna kadar okuduğunuz için teşekkür ederiz. Gitmeden önce:

• Lütfen yazıyı alkışlamayı ve beni takip etmeyi unutmayın! 👏
• Beni takip etmek isterseniz X| Linkedin| Github

İyi günler,
Bol kodlamalar :)

Kaynaklar

• https://github.com/spring-projects/spring-retry

Spring Retry ve Recover Kullanarak Hata Yönetimi 🔁🛠 was originally published in folksdev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mernis & KPS nedir?

Merkezi Nüfus İdaresi Sistemi (MERNİS), Türkiye Cumhuriyeti vatandaşlarının nüfus kayıtlarının merkezi bir veri tabanında tutulduğu bir projedir. Kimlik Paylaşım Sistemi (KPS) ise, MERNİS veri tabanındaki kimlik bilgilerinin kamu kurumları ve yetkilendirilmiş tüzel kişiler tarafından kontrol edilebileceği ve paylaşılabileceği bir hizmettir. Bu hizmetin prosedürleri kabul eden herkese açık olması sayesinde biz de KPS API’sini kullanarak kimlik kontrolünü gerçekleştirebiliyoruz.

KPS servisini kullanabilmek için TC kimlik numarası ile kullanıcı kaydı doğrulayıp oluşturabileceğimiz basit bir proje oluşturalım 👇🏻

Projeyi spring initializer sayfasına giderek oluşturuyoruz. Bu bir maven projesi ve ilgili dependencys: Lombok, JPA, Spring Web, SpringBoot DevTools, PostgreSQL Driver.

Öncelikle PostgreSql’de UserRegister adında bir veri tabanı oluşturalım ve sonrasında projeye gelip resources kısmında properties uzantılı dosyayı yaml uzantılı dosyaya çevirelim. Bize gerekli olan veri tabanı ve jpa tanımlamalarını yazalım.

spring:
  application:
    name: mernisConfig
  jpa:
    properties:
      hibernate:
        dialect: org.hibernate.dialect.PostgreSQLDialect
    hibernate:
      ddl-auto: update
      show-sql: true
  datasource:
    url: jdbc:postgresql://localhost:5432/UserRegister
    username: postgres
    password: test

Model package oluşturup içerisine User sınıfımızı tanımlayalım. Burada bizim için gerekli olan ad, soyad, doğum tarihi ve TC kimlik numarasını tanımlayarak business katmanında kontrol işlemlerini gerçekleştirerek kayıt oluşturacağız.

package com.example.mernisConfig.model;


import jakarta.persistence.*;
import lombok.AllArgsConstructor;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.Setter;

import java.time.LocalDate;

@AllArgsConstructor
@NoArgsConstructor
@Getter
@Setter
@Entity
@Table(name = "users")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private int id;
    private String firstName;
    private String lastName;
    private LocalDate birthOfDateYear;
    private String identityNumber;
    private String email;
}

Oluşturduğumuz User sınıfının UserRepository interface’ini oluşturarak veri tabanı işlemlerini kolaylaştırıyoruz. Servis sınıfını oluşturmadan önce burada kullanacağımız mernis sistemini kurma vakti geldi. Yeni bir package oluşturarak adına ‘mernis’ diyelim. Eğer ilk defa bir web servisi ekleyecekseniz projenize muhtemelen ilgili plugin bulunmayacaktır. Bu yüzden öncelikle easyWSDL plugin ekliyoruz ki dışarıdan servisi ekleyip kullanabilelim.

File üzerine gelerek proje ayarlarına gidelim:

Buradan da plugin kısmına gelerek easyWSDL generator’ı aratalım ve install yapalım:

Oluşturduğumuz package üstüne gelerek sağ click yaparak en alttaki easyWSDL - add web service seçeneğine tıklayarak hesap oluşturuyoruz.

Hesap oluşturduktan sonra, tekrardan add web service diyerek çıkan yeni pencerede URL kısmına kullanacağımız mernis KPS servisini veriyoruz. Language ‘Java’ olarak seçip, işlemi tamamlıyoruz. (https://tckimlik.nvi.gov.tr/Service/KPSPublic.asmx)

Ve artık ilgili sınıflar package içerisinde. Proje dosyasında oluşan jar dosyalarını da module olarak eklememiz gerekli.

File →Project Structure → Modules e gelerek easyWsdl klasöründeki jar dosyalarını seçiyoruz ve bunları projeye yüklüyoruz.

Artık mernis servisini projemize bağladık ve ilgili sınıfları kullanarak kimlik kontrolümüzü gerçekleştiren kodu yazabiliriz. UserService sınıfını oluşturabiliriz. Aşağıdaki servis kodunda mernis package’ında bulunan CQRKPSPublicSoap sınıfından bir obje oluşturuyoruz. (Muhtemelen eğer siz projeyi kendiniz oluşturursanız sınıfların önündeki 3 harf değişecektir.) Bu oluşturduğumuz objede TCKimlikNoDoğrulama metodunu çağırarak ve içerisine obje değerlerini göndererek kontrol ediyoruz. Eğer sonucumuz true dönerse bu bilgilere sahip bir TC vatandaşı bulunmakta, false ise bu bilgilerle kayıtlı bir TC vatandaşı bulunmamaktadır.

package com.example.mernisConfig.service;

import com.example.mernisConfig.mernis.CQRKPSPublicSoap;
import com.example.mernisConfig.model.User;
import com.example.mernisConfig.repository.UserRepository;
import lombok.RequiredArgsConstructor;
import org.apache.coyote.BadRequestException;
import org.springframework.stereotype.Service;

@Service
@RequiredArgsConstructor
public class UserService {
    private final UserRepository userRepository;
    public String registerUser(User user) throws Exception {
        CQRKPSPublicSoap client= new CQRKPSPublicSoap();
        boolean isRealPerson = client.TCKimlikNoDogrula(
                Long.valueOf(user.getIdentityNumber()),
                user.getFirstName(),
                user.getLastName(),
                Integer.valueOf(user.getBirthOfDateYear().getYear()));

        if(isRealPerson){
            userRepository.save(user);
            return "kullanıcı başarıyla kayıt edildi";

        }
        else {
            throw new IllegalArgumentException("Kullanıcı bulunamadı!");
        }

    }

}

En son da controller sınıfımızı oluşturarak kullanıcı oluşturmak için bir post metodu tanımlıyoruz.

package com.example.mernisConfig.controller;

import com.example.mernisConfig.model.User;
import com.example.mernisConfig.service.UserService;
import lombok.RequiredArgsConstructor;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/api/v1/users")
@RequiredArgsConstructor
public class UserController {

    private final UserService userService;

    @PostMapping
    public ResponseEntity<String> register(@RequestBody User user) throws Exception {
        return ResponseEntity.ok(userService.registerUser(user));
 }
}

Kodumuzun son halini doğru kullanıcı bilgileri girerek Postman’den istek atıp doğrulayalım:

Bu kodlara ulaşmak isterseniz Github Repository burada.

Okuduğunuz için teşekkür ederim. Umarım sizler için faydalı bir yazı olmuştur 🫶🏻

Eğer yazılarım ilginizi çekiyorsa beni takip etmeyi unutmayın ✨💐
X | LinkedIn | GitHub

Bir sonraki yazıda görüşmek üzere, sağlıcakla kalın🙌🏻

Dikkat! Kimlik kontrolü: Mernis & SpringBoot was originally published in folksdev on Medium, where people are continuing the conversation by highlighting and responding to this story.