Quantcast
Channel: YazılımPortal - Medium
Viewing all articles
Browse latest Browse all 23

Kubernetes Request & Limit

$
0
0

Kubernetes Resource Limit ve Request

Kubernetes uzerinde node’larda belli miktarda cpu ve memory kaynagi bulunur. Bunun bir kismi kube-system denilen kubernetes kaynaklarina tahsis edilir. Kalan kaynaklar uzerinde calisan pod’lar arasinda paylasilir.

Limit vermedigimizde tum pod’lar ihtiyaci oldugu kadar kaynak ele gecirebiliyor. Ayni anda birden fazla uygulama node uzerindeki kaynaktan daha fazla kaynak ele gecirmeye calistiginda cluster tarafinda sorunlar yasiyoruz. Bunun onune gecebilmek icin tum deployment’larda pod’larimiz icin cpu ve memory limitleri tanimlamaliyiz.

Limit ve Request arasinda nasil bir fark var ?

Request bir pod’a tahsis edilecek resource miktarini belirler. Request edilen kaynak bu pod’a tahsis edilir ve garanti edilir. Yani bir pod baska bir pod’un request ettigi kaynagi ele geciremez.

Limit pod’a tahsis edilen kaynagin uzerinde bir kaynaktir. Ihtiyac halinde kullanabilecegi maximum cpu ve memory kaynagini belirtir. Pod limit’in uzerinde bir kaynak ele geciremez.

Kubernetes cpu ve memory kaynak birimleri nelerdir ?

CPU kubernetes uzerinde core ve millicore cinsinden hesaplanir.

1 core 1000m (millicore) ile ifade edilir.

Ortalama bir production makinasinda 16core yani 16000m kaynak vardir.

Memory ise Gi ve Mi ile ifade edilir. Gi gigabyte cinsini , Mi megabyte cinsini ifade eder.

Ortalama bir production makinasinda 64Gi memory bulunmakta.

Request ve limit verirken nasil karar vermeliyiz ?

Memory icin konusacak olursak deployment’larda kaynak belirlerken uygulamanin saglikli bir sekilde ayaklanmasi icin gerekli minimum kaynaklari belirlemek onemli. Eger uygulamamiz 512Mi ile calistirilabiliyorsa bunun bir miktar uzerinde request etmek saglikli olacaktir.

JVM ortaminda heapsize vs girdigi icin orada heap+system request edilecek memory olarak hesaplanmali.

768Mi guvenli bir limit olarak belirledik ve request memory olarak set ettik.

Limit belirlerken uygulamanin peak yaptigi durumlar dusunulmeli. Eger belli surelerde batch isler yapacak ise bu limitleri belli donemlerde kullanacagi anlamina gelir.

768Mi request edilen bir uygulama icin 1Gi yada 1280Mi memory limit’i verilebilir. Burada onemli olan nokta Limit’in Request ettiginiz kaynaktan fazla olmasi.

CPU icin kademeli olarak arttirim yapilabilir. Eger uygulamanizin cpu kullanimi hakkinda hic bir fikriniz yoksa 100m ile baslayarak. Uygulamayi gozetleyebilirsiniz. Cluster dashboard’dan pod’larin cpu kullanimlarina bakmak fikir verebilir. Heapster gibi bir monitoring araci yuklu ise grafana uzerinden gecmise yonelim cpu kullanimlari fikir verebilir. CPU request’lerini mumkun oldugu kadar dusuk tutmaya calismak cluster uzerinde kaynak yetersizligini onlemek icin onemli bir konu. Burada yine limit request orani 1’e 1.5 yada 1’e 2 olarak verilebilir.

Ornek bir deployment yml:

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
resources:
limits:
cpu: "150m"
memory: "1024Mi"
requests:
cpu: "100m"
memory: "512Mi"

Helm chart icin resource tanimlama ornegi (helm nedir?)

Helm ile values yaml’da her ortam icin farkli resource tanimlanabilir. Ornegin prod’da 200m cpu kullanan bir uygulama icin dev ortaminda 50m cpu yeterli olacaktir. Burada values yaml baz alinir ayrica dev.yml,prod.yml.. uzerinde tanimlanan resource’lar o ortamlar icin values.yml’i ezer.

# Default values for app.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
terminationGracePeriodSeconds: 120
image:
repository: test.dockerhub.com/test-api
tag: stable
pullPolicy: IfNotPresent
secretName: sfront-registry
service:
type: NodePort
port: 8080
probe: http
replicaCount: 1
profile: test
ingress:
enabled: false
resources:
requests:
memory: "1024Mi"
cpu: "200m"
limits:
memory: "2048Mi"
cpu: "400m"
nodeSelector: {}
tolerations: []
affinity: {}

Ornek env bazli yml (prod.yml)

# Production values for app.
service:
type: NodePort
port: 8080
nodePort: 31219
replicaCount: 3
profile: prod
resources:
requests:
memory: "1024Mi"
cpu: "300m"
limits:
memory: "2048Mi"
cpu: "500m"

Daha detayli bilgi icin kubernetes dokumantasyonundan faydalanabilirsiniz: https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/


Kubernetes Request & Limit was originally published in YazılımPortal on Medium, where people are continuing the conversation by highlighting and responding to this story.


Viewing all articles
Browse latest Browse all 23

Latest Images