💻
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

Pod Affinity

PreviousNode AffinityNextTaint and Toleration

Last updated 2 years ago

Was this helpful?

Bazı durumlarda, bizler oluşturduğumuz podun schedule edileceği node üstünde çalışan başka podların olmasını veya olmamasını isteyebiliriz.

Misal, Azure üstünde koşan kubernetes clusterımız var. Bu kubernete clusterın 4 worker node var. Ve bu 4 worker node da, aynı region içerisinde bulunan 2 farklı availability zone üzerinde dağıtılmıştır.

Yani worker node 1 ve worker node 2 availability zone 1 de, worker node 3 ve worker node 4 de availability zone 2 de barınmaktadır.

Farzedelim ki biz frontent , cache ve veritabanından oluşan bir uygulama deploy edeceğiz. İlk olarak veritabanımızı oluşturacak pod tanımını hazırladık ve ve kubernetes api gönderdik ve kubernetes scheduler işini yaptı ve podu çalıştıracağı uygun bir node buldu. Ve varsayalım ki bu node ise, worker node 1, sonrasında frontend uygulamasını deploy ettik ve onu da worker node 3 de schedule etti. Son olarak da, cache podumuzu deploy ettik ve bu pod da son olarak worker node 4 de çalışmaya başladı.

Bu senaryo da bir kaç sıkıntı var,

İlk olarak, frontend podumuz ve veritabanı podumuz ayrı ayrı availability zonelar üzerinde schedule edildiler. Tahmin edebileceğiniz üzere frontend podumuz sürekli olarak veritabanı ile görüşüyor. Sürekli ona veri yazıyor ve ondan veri okuyor. Hemen hemen tüm cloud servis sağlayıcılar 2 availability zone arasında veri transferine ücrete tabi tutulur. Yani biz 2 podu da aynı availability zone üzerinde bulunan worker nodelarda koştursaydık, aynı availability zone üzerinde durdukları için aralarındaki veri transferine para ödemeyecekken, şimdi ayrı availability zone da durdukları için para ödemek zorunda kalacağız. Bunun olmasını engellemek için, node affinity yazarak, podları aynı yere toplayabiliriz. Ama bu seferde her şeyi manuel olarak ayarlamak gerekecek. Fakat bunun yerine şöyle bir şey yapabilseydik, sanırım işleri otomatik olarak kubernetes hallederdi. Eğer ben pod tanımına, bak bu podu oluşturacağın node'u seçerken git veritabanı poduna bak ve o pod hangi availability zone da oluşturulduysa, bu podu da orada oluştur gibi bir tanım ekleyebilseydim bu sorunu çözebilirdik.

Diğer bir istediğimiz bir durumda şu olabilirdi;

Misal frontend ve cache podları ayrı worker node üzerinde oluşturulmuş. Bunları da keşke aynı worker node üzerinde çalıştırabilseydim. Sonuçta cache ve frontend arasında ne kadar az latency olursa, uygulamam o kadar performanslı çalışır.

Bunun kolay yolu da şu olurdu, cache pod tanımında şunu diyebilseydik, git frontend pod'a bak, o hangi node üstünde oluşturulduysa, bu pod da orada oluşturulsun.

Bize tüm bunları sağlayan, Kubernetes özelliği mevcut.

Pod Affinity podumuzun hangi worker node üzerinde oluşturulmaya uygun olduğunu nodelardaki etiketlere göre değil, hali hazırda node da çalışmakta olan podlardaki etiketlere göre sınırlamamıza olanak tanır.

Bizlerin bir pod tanımına ekleyerek, o podun oluşturulacağı node seçimini ve o node üzerinde çalışan veya çalışmayan podların varlığına göre yapabilme imkanı veren özelliğe Pod Affinity diyoruz. Nasıl ki, node affinity de bir podun oluşturulacağı node ve o node da bulunan veya bulunmayan labellara göre seçebiliyorsak, Pod Affinity de ise, bunu ilgili node üzerinde çalışan pod olup, olmadığına göre seçebiliyoruz.

Bizler daha önceden worker nodelarımıza çeşitli labellar eklemeyi gördük ve ekledik. Fakat nodelar üzerinde önceden de tanımlanmış(default gelen) bir çok label mevcuttur.

Her kubernetes node da,

1 - kubernetes.io/arch => İlgili node x64 veya ARM tabanlı bir işlemciye sahip olduğunu belirtir. Değer olarak Amd64 veya ARM değerlerini alabilir. 2 - kubernetes.io/hostname => İlgili node'un, hostname değerini alır.

3 - kubernetes.io/os => İlgili node'un işletim sistemi bilgilerini alır (Linux,Windows)

Labelları bulunur.

Bunun yanında, cloud servis sağlayıcılarının yönetilen Kubernetes hizmetindeki nodelarda ilgili node'un hangi region da bulunduğunu belirten ( topology.kubernetes.io/region ) ve hangi availability zone da bulunduğu belirten, ( topology.kubernetes.io/zone ) anahtarları ile belirtilir.

Örnek bir Pod Affinity tanımı içeren YAML dosyası içeriği,

apiVersion: v1
kind: Pod
metadata:
  name: frontendpod
  labels:
    app: frontend
    deployment: test
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80
---
apiVersion: v1
kind: Pod
metadata:
  name: cachepod
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - frontend
        topologyKey: kubernetes.io/hostname
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: color
              operator: In
              values:
              - blue
          topologyKey: kubernetes.io/hostname
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: deployment
              operator: In
              values:
              - prod
          topologyKey: topology.kubernetes.io/zone
  containers:
  - name: cachecontainer
    image: redis:6-alpine

2. Pod tanını inceleyelim, Pod affinity tanımlarıda aynen node affinity tanımları gibi requiredDuringScheduling ve preferredDuringScheduling olarak hard ve soft gereksinimlere sahip olabilirler. Node affinity tanımlara oldukça benzer. Tek bir fark vardır. Pod affinity tanımlarıonda topologyKey adında bir daha gireriz. İlk tanımda requiredDuringSecheduling seçeneği girili, yani mecbur kılınmış. Bu tanımda diyoruz ki, schedule edileceği worker node üzerinde app=frontend labelina sahip bir pod olmalı. Yani bu podu bu şartı sağlayan host üstünde schedule et. topologyKey kısmında bunu belirtiyoruz. Burada hostname anahatarını seçersek, aynı hostname yani aynı worker node üzerinde bu pod çalıştırılacak.

Misal, diyelim ki hostname yerine "zone" anahtarını seçtik. Bu seferde aynı worker node olmasına gerek yok olmayacaktı. Buraya topology.kubernetes.io/zone yazsaydık, bu podu app=frontend labelli bir podun çalıştığı availability zone daki herhangi bir worker node üzerinde çalıştır. Manasına gelecekti.

Görüldüğü gibi node affinity de çalışacağı worker nodedaki labellara göre seçiyorduk. Pod affinitty de ise, hangi podlarla birlikte çalışacağını seçiyoruz.

Pod Affinity'nin Node Affinity göre bir farkı da anti-affinity tanımlarının ayrı yapılmasıdır. node anti affinity kısmını not-in ile halledebiliyorduk. Fakat pod anti affinity kısmını özel olarak tanımlamamız gerekiyor. Bunu da podAntiAffinity anahtarı ile yapıyoruz.

Örnekte bulunan antiAffinity kısmını inceleyecek olursak, Bu podu deployment=prod tanımına sahip olan bir pod ile, aynı zone da schedule etme diyoruz.

Bu YAML dosyasını deploy edersek şu olur;

  • Öncelikle frontend pod adındaki pod schedule edilecek. Gördüğünüz gibi app=frontend labeli eklemişiz. Bu da bizim frontend podumuzu temsil ediyor.

  • Sonrasında ise, 2.podumuz olan, cachepod isimli podumuz deploy ederken, kubernetes pod affinity kurallarına bakacak, İlk kural olan RequireDuring kısmından bahsedersek, burada şunu diyoruz, Bu pod mutlaka app=frontend labelina sahip bir pod ile aynı node üzerinde çalıştırılsın. Eğer bu şekilde birden fazla node varsa, git color=blue labelina sahip bir podun çalıştığı worker node varsa, onu seç. Ve mümkünse bu seçtiğin worker node buludunduğu zone içerisinde deployment=prod labelina sahip bir pod bulunmasın.

🍎
🔌