💻
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

Node Affinity

PreviousConfigMapNextPod Affinity

Last updated 2 years ago

Was this helpful?

Node Affinity kavramsal olarak node selector'a benzer ve nodelara atanan etiketlere göre podumuzun hangi node üstünde schedule edilmeye uygun olduğunu kısıtlamamıza olanak tanır.

Podlarımızın, uygun worker nodelar üzerinde oluşturulması için, imkan sunan pod opsiyonlarımızdandır. Node Selector ile çok benzerdir. Aynı şekilde pod tanımına ekleriz. Podumuzun scheduler edileceği node üstünde pod tanımında belirttiğimiz label'in olmasını bekleriz.

Affinity tanımı, pod tanımı içerisinde "affinity" parametresi altında eklenmektedir. Bu parametre altında kullanabileceğimiz 2 seçenek mevcuttur.

  • requiredDuringSchedulingIgnoredDuringExecution

  • preferredDuringSchedulingIgnoredDuringExecution

apiVersion: v1
kind: Pod
metadata:
  name: nodeaffinitypod1
spec:
  containers:
  - name: nodeaffinity1
    image: ubuntu
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: app
            operator: In #In, NotIn, Exists, DoesNotExist
            values:
            - blue
---
apiVersion: v1
kind: Pod
metadata:
  name: nodeaffinitypod2
spec:
  containers:
  - name: nodeaffinity2
    image: ubuntu
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: app
            operator: In
            values:
            - blue
      - weight: 2
        preference:
          matchExpressions:
          - key: app
            operator: In
            values:
            - red
---
apiVersion: v1
kind: Pod
metadata:
  name: nodeaffinitypod3
spec:
  containers:
  - name: nodeaffinity3
    image: alpine
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: app
            operator: Exists #In, NotIn, Exists, DoesNotExist
  1. pod tanımında bulunan, requiredDuringSchedulingIgnoredDuringExecution seçeneği, şu demektir. Bu podu oluştururken, mutlaka alta yaptığım eşleşmeye uygun node bul ve bu podu orada oluştur. Uygun bir node bulamazsan, pod oluşturulmasın ve "pending" status da, uygun node bulana kadar beklesin. Bu pod tanımını kubernetes API server'a gönderirsem, şu olacak. Kubernetes tüm worker nodelarda, app=blue şeklinde bir label arayacak. Eğer bu labelin olduğu uygun bir worker node görürse bu podu orada schedule edecek. Tanım required olduğu için, Eğer bu labela sahip bir worker node bulamazsa, schedule edilmeyecek. Pod "pending" de bekleyecek. Kısacası required mutlaka sağlanması gereken eşleşme varsa, onu belirttiğimiz parametredir.

Burada operator olarak kullanabileceğimiz birkaç seçenek daha mevcuttur. Bu seçenekler aslında node selector'dan ayrışmasını sağlıyor. app in blue tanımı yaptığımızda, app anahtarına blue değerinin atanma şartı oluşturuyoruz. Yani pod app=blue labela sahip, worker node bulursa schedule edilecek. Fakat burada, "in" yerine "notin" deseydik, Bu sefer pod, üstünde app=blue labeli tanımlanmamış bir worker node üstünde oluşturulacaktır.

operator kısmına, "exists" tanımı girseydik, ve değeri silseydik. şu olacaktı; bu podu oluşturmak için, üstünde "app" anahtarı tanımlanmış herhangi bir worker node bul demek olacaktı. Yani value(değeri) kısmı önemli değil. sadece "app" anahtarı olması yeterli.

DoesNotExists seçeneği ise, tam tersidir. Üstünde "app" abahtarı olmayan bir worker node bul ve orada çalıştır.

requiredDuringSchedulingIgnoredDuringExecution seçeneğinde, şart sağlanmazsa pod oluşturulmaz.

2. Pod tanımında bulunan, preferredDuringSchedulingIgnoredDuringExecution seçeneği şu manaya gelir; Buradaki tanıma bak, bu podu, bu tanıma uygun node üstünde oluştur. Fakat bu tanıma uygun bir node bulamazsanda "pending" olarak bekletme, başka bir node bul ve bu podu orada oluştur. Preferred tanımında gördüğünüz üzere, "weight" de girebiliyoruz. Weight 1 ile 100 arasında bir değer verebiliyoruz. Ve birden fazla tanım girildiyse, onların hangisinin daha önce değerlendirileceğine bakıyor. Örneğimizde 2 tanım girili durumda, 1. tanımdaki weight :1 seçili, 2.tanımda weight:2 seçili. 2, 1'den daha büyük olduğu için, daha önceliklidir. Biz bu podu oluşturduğumuzda şu olacak; Scheduler tüm nodelara bakacak ve, app=blue ve app=red labellarına sahip nodeları listeleyecek. Bunlardan app=red weight değeri daha yüksek olduğu için, Eğer bu etikete sahip node varsa, pod buada oluşturulacak. Eğer bu worker node üstünde yer yoksa, veya label yoksa bu seferde app=blue olan node seçilecek. Eğer bu node da yer yoksa veya bu labellere sahip hiçbir node bulamazsa, uygun olan herhangi bir worker node üstünde, pod oluşturulacak.

Uzun lafın kısası, required olarak girildiyse tanım, mutlaka bu şart yerine getirilmelidir. Fakat preferred olaran girildiyse, bu şartı karşılamayı dener fakat karşılayamazsa, yine de schedule eder.

IgnoredDuringExecution kısmı şu demektir; Biz bir pod oluşturduk, pod buradaki tanıma göre bir worker node buldu ve orada schedule oldu. Ve çalışmaya başladı. Fakat aradan zaman geçti ve biz bu çalıştığı worker nodedan podun node seçiminde kullandığı labeli sildik. Eğer Affinity altında IgnoredDuringExecution seçeneği seçiliyse, pod bir kere schedule edildikten sonra, çalışmaya devam edecek anlamına gelir. Zaten hali hazırda kubernetes de bunun için farklı bir alternatif yok. Yani RequireDuringExecution veya PreferredDuringExecution tanımları yok. Belki ileride bu özellikleri de görebiliriz.

Özetle,

  1. pod, app=blue labelini şart koşuyor. Bu labela sahip node yoksa veya label var ama pod için yer yoksa, pod oluşturulmaz. requiredDuringSchedulingIgnoredDuringExecution seçeneğini çok fazla kullanmayı tercih etmeyiz ki, misal SSDli nodelarda pod çalıştırmak için nodelara disk=ssd labeli ekledik. Ancak bir zaman sonra, bu nodelar dolacaktır ve yeni pod schedule etmek için yer kalmayacaktır. Bu durumda podumuz oluşturulmayacaktır. (En azından bir süre). Uygun node bulana kadar "pendig" status da bekleyecektir. Yer olmasa bile, podumuzun farklı bir node da(misal disk=ssd labelina sahip olmayan) oluşturulmasını isteyebiliriz ki servisimiz, uygulamamız çalışabilsin. Bu nedenle preferred tanımı daha kullanışlı gözüküyor.

-----------------------------------------------------------------------------------------------------

  1. POD app=blue labeli olmasını şart koşuyor.

  2. POD app=blue veya app=red labellerinin olmasını istiyor ancak şart koşmuyor.

  3. POD app adında, bir anahtar(label) olacak ama değerinin ne olduğu ile ilgilenmiyor. Sadece "app" adında label olup, olmadığına dikkat ediyor.

🍎
🖥️