💻
Cheet Sheets
  • 🦁Başlarken
  • 🟧DevOps Pre-Requisite
    • ❤️Why Linux? | Linux Basics #1
    • 💛Vi Editor | Linux Basics #2
    • 💙Basics Commands | Linux Basics #3
    • 🧡Package Managers | Linux Basics #4
    • 💚Services | Linux Basics #5
    • 💛Networking Basics
    • 🤎DNS Basics
    • 🩶Applications Basics
    • 🟨Java introduction
    • 🟩NodeJS Introduction
    • 🟦Python Introduction
    • 🟪GIT Introduction
    • 🟧Apache Web Server Introduction
    • ⬛Apache Tomcat
    • 🟫Python Flask
    • 🟥Node.js Express App
    • 🟨Databases
    • 🟩MySQL
    • 🟪MongoDB
    • 🟨SSL & TLS
    • 🟦YAML & JSON - JSON Path
    • ⬛Labs Resources
  • 🍎Kubernetes
    • 🍏Kubernetes: Nedir ?
    • 🍒Bileşenler
    • 🍵Kubectl ve Versiyon
    • ❤️Pod
    • 🏷️Label ve Selector
    • 🔎Annotation
    • 📲Namespaces
    • 📦Deployments
    • 🔁ReplicaSet
    • 🔙Rollout & Rollback
    • 🌐Networking - 1
    • 🌏Service
    • 🛠️Liveness Probe & Readiness Probe
    • 🥐Resource Limits
    • 💰Environment Variables
    • 📃Ephemeral Volumes
    • 🔑Secrets
    • 🌂ConfigMap
    • 🖥️Node Affinity
    • 🔌Pod Affinity
    • ✍️Taint and Toleration
    • 🔦DaemonSet
    • 🧀PV/PVC
    • 🌜Storage Class
    • 🗿StatefulSet
    • 🕹️Job & Cronjob
    • 🔐Authentication
    • 📏Role-based access control (RBAC)
    • 🈷️Service Account
    • 📈Ingress
    • 📂ImagePullPolicy & ImageSecret
    • 📖Static Pods
    • 🌐Network Policy
    • 🫐Helm Nedir?
    • 📽️Prometheus Stack - Monitoring
    • 💼EFK Stack - Monitoring
    • 🥳CRD & Operator
  • 🧑‍⚕️GIT & GITHUB
    • 👉Girizgah
    • 🌴Branch
    • 🤝Merge
    • 🤔Conflict - Rebase
    • 🇸🇴Alias
    • 🛑Gitignore
    • 🥢Diff
    • ◀️Checkout
    • 🔦Stash
    • 👉Other
  • ☁️AWS
    • 🪣S3
    • 🚙EC2
    • ⚖️ELB
    • 🤝Auto Scaling
    • 🗄️EFS
    • 🔐VPC
    • 🎆CloudFront
    • ❤️Route53
    • 🦈RDS
    • 🏢ElastiCache
    • 🔭CloudWatch
    • 👀CloudTrail
    • 📃CloudFormation
    • 🔕SNS
    • 📬SQS
    • 🎇SWF
    • 📧SES
    • 📦Kinesis
    • 📐AWSConfig
    • 👩‍🏭OpsWork
    • 🚀Lambda - Api Gateway
    • 📌ECS - EKS
    • 🔑KMS
    • 📂Directory Service
    • 🏐Snowball
    • 💾Storage Gateway
    • 💽Volume Gateway
    • 📼Tape Gateway
    • 🏠Organizations
    • 🔙Backup-Transfer-CloudShell
    • 🆔IAM
    • 📀DataSync
    • 🗃️FSx
    • 🎒Aurora Serverless
    • 🌐Global Accelerator
    • 💪HPC
    • 🎰Outposts
    • 🗼Others
  • 👨‍🔬Ansible
    • 👉Girizhah
    • 📔YAML
    • ⚙️Komponentler
    • 🎒Inventory
    • 🏑ad-hoc
    • ▶️Playbook
  • 👨‍⚕️PROMETHEUS
    • 📈Terminoloji
    • 🦯Ubuntu 20.04 Prometheus Kurulum
    • 🗒️prometheus.yml dosyasına ilk bakış:
    • 🧭promQL up query
    • 📇Exporters
    • 🔦promQL Data Types
    • 🦯Selectors & Matchers
    • 🔢Binary Operators
    • 💀ignoring and on
    • ✍️Aggregation Operators
    • 🧠Functions
    • 🖊️Alıştırma
    • 💻Client Libraries
    • 🐍Examining the data of our Python application
    • 🐐Examining the data of our GO application
    • ⏺️Recording Rules
    • 💡rate functions
    • ⏰Alerting
    • ⌚Alert Routing
    • ⏰Slack integration with Prometheus
    • 🤯PagerDuty integration with Prometheus
    • ◼️BlackBox exporter
    • 📍Push Gateway
    • 🪒Service Discovery
    • 🧊kube cadvisor with external prometheus
    • 👉aws with prometheus
    • ☁️CloudWatch Exporter
    • 👨‍🚒mysql exporter
    • 🛃Custom exporter with Python
    • ⚙️Prometheus with HTTP API
    • 🤖Prometheus Federation For Kubernetes
    • 📺Grafana
    • ⁉️Prometheus: Ne zaman kullanılmalı? Ne zaman kullanılmamalıdır?
  • 🍪Sheets
    • 🛳️Docker Sheets
    • 🐐Kube Sheets
  • 🔢12 Factor APP
    • 🏗️Introduction
    • 1️⃣Codebase
    • 2️⃣Dependencies
    • 3️⃣Concurrency
    • 4️⃣Processes
    • 5️⃣Backing Services
    • 6️⃣Config
    • 7️⃣Build, release, run
    • 8️⃣Port binding
    • 9️⃣Disposability
    • 🔟Dev/prod parity
    • 🕚Logs
    • 🕛Admin processes
  • ☁️Azure 104
    • 👨‍👨‍👧‍👧Azure Active Directory ( Entra ID )
    • 💰Subscriptions
    • 🌎Virtual Network (VNET)
    • 💻Virtual Machines
    • 🧑‍🌾Load Balancing
    • 🥍Network Advanced
    • 🪡Automating Deployment and Configuration
    • 💂Securing Storage
    • 📓Administering Azure Blobs and Azure Files
    • 🔧Managing Storage
    • 🎁App Service
    • 🛳️Azure Container
    • 🥇Backup And Recovery
    • 🪐Network Watcher
    • ⏰Resource Monitoring And Alerts
  • ⛅AZURE 305
    • 🆔identity and access management
    • 💼Desing Azure AD (Entra ID)
    • 👨‍💼Desing for Azure B2B
    • 🛃Desing for Azure B2C
    • 💳Design for MFA and Conditional Access
    • ⛑️Design for Identity Protection
    • 🚶Access Reviews
    • 🚦Managed identity Demostration
    • 🔐Key Vault Demostration
    • 👑Governance hierarchy
    • 💠Design for Management Groups
    • 🔑Desing for Subscriptions
    • 🍇Desing for resource groups
    • 📟Design for resource tags
    • 🚷Azure Policy & RBAC
    • 🫐Desing For Blueprints
    • 🪡Desing for Virtual Networks
    • 🛫Design for on-premises connectivity to Azure
    • 🔽Design for network connectivity
    • 📦Design for application delivery
    • 🥞Design for network security and application protection
    • 📕Choose a compute solution
    • 🌊Design for virtual machines
    • 🔋Azure Batch Demostration
    • 🛰️Design for Azure App Service
    • ⛲Design for Azure Container Instances
    • 🎢Design for Azure Kubernetes Service
    • 📠Azure Functions Demostration
    • 💪Azure Logic Apps Demostration
    • 🧑‍💼Design for data storage
    • 🎞️Design for Azure storage accounts
    • 🌟Choose the storage replication
    • 📹Azure blob storage - Lifecycle & immutable demo
    • 🥌Azure Files Demostration
    • 🕸️Design Azure disks
    • 🦼Design for storage security
    • 🔮Azure Table Storage And Cosmos DB Demostration
    • 🟧Azure SQL Solutions
    • 🎡Azure SQL Database - Purchasing models
    • 🕯️Database availability
    • 📜Data security strategy
    • 🧮Azure SQL Edge
    • 🚲Azure Data Factory
    • 🔅Azure Data Lake Storage
    • 🧘‍♂️Azure Databricks
    • 🎒Azure Synapse Analytics
    • 🅰️Azure Stream Analytics
    • 📼Data flow strategy
    • 🍥Cloud Adoption Framework
    • ☣️Azure Migration Framework
    • 🦿Assessing workloads
    • 🪡Migration tools
    • 🤖Azure Database migration
    • 👥Storage migration
    • 👜Azure Backup
    • ⏲️Azure Blob Backup and Recovery
    • 💈Azure files backup and recovery
    • 🎞️Azure VM backup and recovery
    • 🧺Azure SQL backup and recovery
    • ⏰Azure Site Recovery
    • 📩Differentiate event and message
    • ✈️Azure messaging solutions
    • 🚜Event Hub
    • 🥍Application optimization solution
    • 🎁Application lifecycle
    • 📺Azure Monitor
    • 🅱️Log Analytics
    • 👥Azure workbooks and Insights
    • 🚌Azure Data Explorer
  • Github Actions
    • Github Actions Nedir?
    • Workflow & Schedule Triggers
    • Single and Multiple Events
    • Manuel Events
    • Webhook Events
    • Conditional Keywords For Steps
    • Expressions - 1
    • Expressions - 2
    • Runners
    • Workflow Commands
    • Workflow Context
    • Dependent Jobs
    • Encrypted Secrets
    • Configuration Variables
    • Default & Custom Env Varb
    • Set Env Varb with Workflow Commands
    • Github Token Secret
    • Add Script to workflow
    • Push Package #1
    • Push Package #2 Docker
    • Service Containers
    • Routing workflow to runner
    • CodeQL Step
    • Caching Package and Dependency Files
    • Remove workflow Artifact
    • Workflow Status Badge
    • Env Protection
    • Job Matrix Configuration
    • Disable & Delete Workflows
    • Actions type for Action
    • Inputs and Outputs for actions
    • Action Versions
    • Files and Directories for Actions
    • Exit Codes
    • Reusable Workflow & Reuse Templates for Actions and Workflows
    • Configure Self Hosted Runners for Enterprise
  • Loki
    • What is Loki?
    • Architecture of Loki
    • Install Loki For Ubuntu
    • Install Promtail For Ubuntu
    • Querying Logs
    • Loki in Kubernetes
    • Deploying Loki in Kubernetes
    • Connecting to Grafana
    • Viewing Kubernetes logs
    • Promtail Customize & Pipeline
  • Ansible
    • Ansible Introduction
    • Introduction to Ansible Configuration Files
    • Ansible Inventory
    • Inventory Formats
    • Ansible Variables
    • Variable Types
    • Registering Variables and Variable Precedence
    • Variable Scoping
    • Magic Variables
    • Ansible Facts
    • Ansible Playbooks
    • Verifying Playbooks
    • Ansible lint
    • Ansible Conditionals
    • Ansible Conditionals based on facts, variables, re-use
    • Ansible Loops
    • Ansible Modules
    • Introduction to Ansible Plugins
    • Modules and Plugins Index
    • Introduction to Handlers
    • Ansible Roles
    • Ansible Collections
    • Introduction to Templating
    • Jinja2 Templates for Dynamic Configs
  • 🅰️Ansible Advanced
    • Playbook run options
    • Facts
    • Configuration files
Powered by GitBook
On this page

Was this helpful?

  1. Kubernetes

Resource Limits

Containerlar biz aksini belirtmediğimiz sürece varsayılan olarak, üzerinde çalıştıkları hostun CPU ve Memory kaynaklarına sınırsız şekilde erişirler. Yani biz 8 GB memory sahip bir sistem üzerinde container çalıştırdığımız zaman, bu container içerisindeki uygulama 8 GB memory 'nin tamamını kullanabilir. Keza aynı şekilde, tüm CPU çekirdeklerini de kullanabilir.

Bu durum özellikle kubernetes gibi yüzlerce container çalıştırdığımız dağıtık yapılarda, bizim için sorun oluşturur. Eğer bir pod koştuğu hostun üzerindeki tüm kaynakları tüketiyorsa, bu diğer podların işlerini düzgün yapmayacağı anlamına gelir. Bu nedenle, bu podların içerisinde çalışan, containerların ne kadar cpu ve memory kullanabileceklerini kısıtlamamız gerekmektedir. Pod tanımlarımızda, kullanabileceğimiz request ve limit opsiyonları bize bu imkanı verir.

Cpu kaynağı, CPU birimleri olarak ölçülür. Kubernetes de bir CPU şuna eşdeğerdir;

  • AWS vCPU

  • GCP Core

  • Azure vCore

  • Hyperthread Bare-Metal

Kesirli değerlere izin verilir. 0.5 CPU talep eden, bir container 1 CPU talep eden, bir container 'ın, yarısı kadar CPU alır. Mili alamında M son ekini kullanabiliriz.

Örneğin, 100m CPU, 100Milicpu ve 0.1 CPU aynıdır. 1M'den daha fazla ince hassasiyete izin verilmez. CPU her zaman, mutlak bir miktar olarak talep edilir. Asla göreli olarak talep edilmez.

Misal;

1 CPU core kullanmak için,

cpu:"1" = cpu="1000" = cpu:"1000m"

1 CPU 'nun %10nu kullanması için,

cpu:"0.1" = cpu:"100" = cpu:"100m"

Kubernetes de CPU kısıtlamaları şu şekilde ayarlanır;

Her worker node'un belirli CPU kaynakları mevcuttur. Bu kaynaklar cloud üstünde yada sanal olarak çalşan stemlerde vCPU olarak, bare-metal sunucularda hyper thread olarak adlandırılır.

Biz bir pod tanımına cpu:1 tanımı eklersek, O pod 'un çalıştığı node üstünde core'lardan, sadece 1 tanesini kullanacağı anlamına gelir. Başka bir yazım şekli daha vardır. Her core 1000ms yani 1000mili cpu'luk güç demektir. Biz eğer cpu:100m yaparsak, pod çalıştığı host üstünde 1 core'un 10'da 1' gücüne erişebilir anlamına gelecektir. Yani, cpu:1 ile cpu:1000m aynı şeydir. Keza 0.1 cpu ile cpu:100m de aynıdır.

Memory tanımı daha kolaydır;

Cluster da mevcut durumda kullanılabilir bellek varsa, bir container belirlenen bellek isteğini aşabilir. Ancak bir container bellek sınırından fazlasını kullanmasına izin verilmez. Bir container sınırından daha fazla bellek ayırırsa, container sonlandırma için aday olur. Container limitinin ötesinde, bellek tüketmeye devam ederse, container sonlandırılır. Sonlandırılmış container yeniden başlatılabiliyorsa, diğer herhangi bir runtime hatası türünde, olduğu gibi kubelet onu yeniden başlatır.

Containerın kullanabileceği maksimum memory 'i, byte cinsinden tanımlayabiliriz. Örneğin, memory:64m dersek, bu containerın, en fazla 64megabyte memory kullanmasına izin verdiğimiz anlamına gelir.

Buradaki m: megabyte g:gigabyte k:kilobyte kısaltmasıdır. Bunların yerine memory hesaplamasında kullanılan 2nin katlarını kullanan gösterim şekli olan, kibibyte,mebibyte,gibibyte tanımlarıda desteklenir.

CPU ve Memory kısıtlama tanımlarını, iki ayrı bölümde tanımlayabiliyoruz. Bunlar, request ve limit parametreleri.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: requestlimit
  name: requestlimit
spec:
  containers:
  - name: requestlimit
    image: obnet/stress
    resources:
      requests:
        memory: "64M"
        cpu: "250m"
      limits:
        memory: "256M"
        cpu: "0.5"

Request altında tanımladığımız değerler şu anlama geliyor, Kubernetes bu pod'u oluşturmaya başladığı zaman, scheduler bu podun oluşturacağı node seçecek. Bu seçme aşamasında kubernetese şunu diyoruz, Bu podu en az 64megabyte memory, 250m milicpu yani çeyrek cpu core'un erişilebilir olduğu bir node üzerinde oluştur. Kısacası request kısmı bu podun oluşturulabilmesi için, minimum ne kadarlık boş kaynağın olması gerektiğini belirtiyor. Scheduler node seçiminde bu parametreleri de göz önüne alacak ve en az bu kadarlık kaynağın boş olduğu bir node seçecek. Eğer boşta 64mbyte memory ve 250m cpu sahip(çeyrek cpu), bir node bulamazsa, bu pod oluşturulmayacak.

Limit kısmı ise, tahmin edebileceğiniz üzere, bu containerın en fazla kullanabileceği sistem kaynağını belirtiyor. Yukarıdaki örnekte şunu diyoruz,

Bu pod içerisinde oluşturulan container, en falza 256megabyte memory kullanabilsin, en çok da yarım cpu (0.5) core 'na erişebilsin. Gördüğünüz gibi cpu kısmını istersek "0.5" yada "1" gibi belirtebiliyor, yada "250m" gibi milicpu halinde yazabiliyoruz. Yani buradaki "0.5" yerine "500m" de yazsak aynı olurdu.

Bu podu oluşturduğumuz da şu olacak, Öncelikle scheduler üstünde en az 64megabyte memory ve çeyrek cpu core kaynağının boşta olduğu bir node bulacak, ve bu pod o node üzerinde oluşturulacak. Pod oluşturulacak ve container çalışmaya başlayacak. Bu container ise, en fazla yarım cpu (0.5) core 'unun gücüne denk gelecek şekilde bir CPU kullanabilecek ve sistemden en fazla 256mbyte allocate edecek.

Bu Container eğer yarım core 'dan fazla CPU kaynağına erişmek isterse ne olacak?

Bu durum mümkün olmayacak, CPU da belirlediğimiz Limit neyse, bu container en fazla o kadar CPU kaynağına erişebilecek.

Memory kısmında belirlediğimiz değer, bu containerın maksimum kullanabileceği memory değeridir. Fakat container bu değere geldiği zaman, daha fazlasını kullanamaz diye bir durum söz konusu değildir. Memory allocation CPU gibi çalışmıyor. teknik olarak farklı şeyler.

Bu nedenle, bu container içerisindeki uygulama sistemden daha fazla ram talebinde bulunabiliyor. Sistem varsayılan olarak bunu engelleme şansına sahip değil. İşte bu nedenle, eğer container memory limitine geldiğinde daha fazla memory allocate edilmesi için bir mekanizma olmadığından, bu duruma geldiğinde OOMKilled (out off memory) kill durumuna geçerek restart ediliyor. Eğer uygulamamız burada belirttiğimiz, memory kısıtından daha çok memory talep ederse pod restart edilecek. Bu nedenle, bu kısıtları uygulamamızın davranışına göre belirlememizin davranışına göre belirlememiz gerekiyor.

Kubernetes node'lar üstünde cpu ve memory kullanımının kontrol edilmesi.

kubectl top node 
# kubectl top node "node_ismi" ile tekil bakılabilir 

Kubernetes pod'lar üstünde cpu ve memory kullanımının kontrol edilmesi.

kubectl top pod 
# kubectl top pod "pod_ismi" ile tekil bakılabilir 

PreviousLiveness Probe & Readiness ProbeNextEnvironment Variables

Last updated 3 years ago

Was this helpful?

🍎
🥐