💻
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
  • SideCar Container (Çoklu container pod)
  • Init Container (Multi Container)

Was this helpful?

  1. Kubernetes

Pod

  • Pod'lar kubernetes de oluşturabileceğimiz ve yönetebileceğimiz en küçük birimlerdir.

  • Pod'lar bir veya daha fazla container barındırabilir. Ama çoğu durumda pod tek container barındırır.

  • Her pod'un eşsiz bir ID'si bulunur.

  • Her pod eşsiz bir IP adresine sahiptir.

  • Aynı pod içerisindeki containerlar, aynı node üstünde çalıştırılır ve bu containerlar birbirleriyle localhost üzerinden haberleşebilirler.

# Pod oluşturma
kubectl run firstpod --image nginx --restart never

# Pod hakkında bilgi almak için
kubectl describe pods firstpod

# Pod loglarına bakmak için, dilersek -f parametresi ile logları canlı izleyebiliriz.
kubectl logs firstpod 

# Pod içerisinde komut çalıştırmak
kubectl exec firstpod -- ls

# Pod içerisine bağlanmak
kubectl exec -it firstpod -- /bin/sh

# Pod silmek
kubectl delete pods firstpod

Bir image registry belirtmezsek, kubernetes default olarak docker image registry kullanır.

  • Oluşturacağımız pod 'ları yml dosyasında belirtip, pod 'dan istediğimiz özellikleri ve gereksinimlerimizi yml dosyasında belirtip, o dosyadan pod oluştururuz.

YML içerisinde bulunması zorunlu olan parametreler,

  • api version

  • kind

  • metadata

Kind, Oluşturmak istediğimiz objenin ne objesi olduğunu tanımladığımız yerdir. [pod,service,deployment, vb] Örneğin, pod objesinin API versiyonunu öğrenmek için, "kubectl explain pods" yazıp, versiyon bilgisine ulaşabiliriz.

Metadata, Obje ile ilgili uniq bilgileri tanımladığımız alan. Birden çok alt başlık olabilir, name,label vb.

Spec, Oluşturmak istediğimiz objenin özelliklerini belirtiriz. Örneğin, container,service objelerinin özellikleri vb. Her obje tipine göre burada tanımlayacağımız bilgiler değişir.

kubectl apply -f pods1.yml
# Komutu ile yml dosyasını kubernetes 'e bildirerek bu yml içerisinde belirttiklerimizi
oluşturmasını isteyebiliriz.

kubectl edit pods firstpod
# Komutu ile pod ayarlarını güncelleyebiliriz.
  • Pod yaratılırken pod'umuz "pending" kısmında kalıyorsa, kube scheduler servisi pod'umuz için uygun bir node bulamamış olabilir.

  • Cluster 'da bulunan tüm node'larda "kubelet" adında bir servis çalışır. Görevi bulunduğu node 'a atanmış görevleri tespit edip, yeni yaratılmış görev,pod vb varsa, bunu tespit edip hemen işlemlere başlar.

  • İlk olarak pod tanımında girilmiş container'lara bakar, bu container'ların oluşturulacağı imajları sisteme indirmeye başlar. Eğer bir şekilde bu imajları indiremezse "err image pull" ardından, "image pull backoff" aşamasına geçer.

  • Eğer böyle bir hata görürseniz, pod 'un imajı repository'den çekemediği ve bunu tekrar tekrar denediği anlamına gelir.

  • Eğer imaj da sorun yoksa, kubelet servisi o node 'da bulunan container engine ile haberleşir ve ilgili container'ın oluşturulmasını sağlar. Container çalışmaya başladığında, pod running duruma geçer. Bu nokta da pod oluşturulmuş olur.

Restart Policy,

Always : Hangi durum da container kapatılırsa kapatılsın. Kubelet bu container'ı yeniden başlatır. Never : Hiç bir durum da yeniden başlatılmaz. On-failure : Hata kaynaklı kapanırsa, yeniden başlatılır.

Pod 'un altında bulunan container'lar çalışmaya devam ettikçe pod running olarak devam eder. Pod işini bitirip kapandığında restart policy never durum da ise, pod yaşam döngüsü succeded olarak yaşam döngüsünü tamamlar.

Eğer Restart policy never veya on-failure olarak ayarlıysa, container'lardan biri hata verip kapanırsa, bu sefer pod 'un status kısmı failed (error) olarak işaretlenir ve yaşam döngüsünü böyle tamamlar.

Restart policy always olarak seçiliyse, container'lar hatadan dolayı da kapansa, normal bir şekilde de kapansa yeniden başlatılır. Dolayısıyla pod succeded veya failed durumuna geçmez. Bunun yerine pod 'un içerisinde bulunan container'lar tekrar başlatılır ve running state devam eder.

Kubernetes pod'un sürekli yeniden başlatma işini belirli bir sıklıkla yapıyorsa, bazı şeylerin ters gittiğine kanaat getirir ve pod'u "CrashLoopBackOFF" durumuna sokar.

Crash Loop BackOff : Pod sürekli fail duruma düşüp veya farklı sebeplerden dolayı yeniden başlatılırsa, bu duruma geçer. Bu duruma geçen container aralıklarla kontrol edilir ve her geçen süre boyunca yeniden başlatma aralıkları uzar. Eğer container tekrar çökmezse running duruma geçer. Eğer halen çalışmayı bırakırsa 5 DK aralıklarla pod 'un içerisinde bulunan container yeniden başlatılmayı dener.

SideCar Container (Çoklu container pod)

apiVersion: v1
kind: Pod
metadata:
  name: mc1
spec:
  volumes:
  - name: html
    emptyDir: {}
  containers:
  - name: 1st
    image: nginx
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
  - name: 2nd
    image: debian
    volumeMounts:
    - name: html
      mountPath: /html
    command: ["/bin/sh", "-c"]
    args:
      - while true; do
          date >> /html/index.html;
          sleep 1;
        done

Kubernetes ana uygulamaya (container) bağlı ve onunla network seviyesinde izolasyon olmadan, ve gerektiği durumda aynı depolama alt yapısını kullanabilecek uygulamaları (container)ları pod içerisinde 2.container olarak çalıştırma imkanı sağlıyor.

Birlikte scale edilmesi gereken, birbirleriyle network ve storage seviyesinde erişmesi gereken container'ları(uygulamalar) aynı pod içerisinde ayrı ayrı container'lar olarak çalıştırabiliyoruz.

Aynı pod içerisinde, tanımlanmış tüm container'lar aynı worker node üzerinde oluşturulur.

Container'lar, ayrı birer ünitedir. Fakat pod'un lifecyle içerisinde yönetilir. Yani pod oluşturulunca 2 container birden oluşturulur. Pod silinince, 2 container birden silinir.

Aynı pod içerisinde bulunan container'lar arasında network lifecyle bulunmaz. Yani aynı pod içerisinde çalışan A ve B container'ları birbirlerine localhost üzerinden ulaşabilir. Bunlar network bakımından sanki aynı sunucu üzerinde çalışan proccess'ler gibidir.

Tek bir volume yaratılarak, her 2 container'a mount edebiliriz. Böylelikle aynı dosyalar üzerinde çalışılabilir.

Sidecar container'lar aynı IP adresine sahip olurlar.

# Multi Container pod kullanarak oluşturduğumuz container'lardan birinin shell'ine
bağlanmak
kubectl exec -it mc1 -c 2nd -- /bin/sh
Tek bir container olsaydı, -c ile container ismi vermemize gerek olmazdı.

# Pod içerisinde bulunan 1st container'ın loglarını inceliyoruz.
kubectl logs -f mc1 -c 1st

# Kubectl'i çalıştırdığımız sunucunun 8080'ine gelen istekleri, kubernetes
cluter içerisindeki mc1 isimli pod'un 80 portuna yönlendir diyoruz.
kubectl port-forward pod/mc1 8080:80 --address='0.0.0.0'

Init Container (Multi Container)

Aynı pod içerisinde birden fazla container tanımlamak için kullanılır. Asıl uygulama container başlatılmadan önce ilk olarak init container çalışır.

İnit container yapması gereken işleri tamamlar ve kapanır.

Uygulama container, init container kapatıldıktan sonra çalışmaya başlar. Inıt container işlemleri tamamlamadan uygulama container başlamaz. Ana uygulama başlamadan önce çalışıp, eksik paketler vb varsa init container'ı bu nedenle kullanabiliriz.

Uygulama çalışmadan önce, tamamlamamız gereken şeyler varsa, bunları tamamlamadan esas uygulamayı çalıştırmak mantıklı değilse kullanılır.

Misal, uygulamamızın bağımlı olduğu, başka bir uygulama veya servis var. Eğer bu ayakta veya hazır değilken uygulamayı başlatırsak uygulamada sıkıntı çıkıyor. Bu durumda pod tanımına bir init container ekler ve bu init container'ın, bu servisi gözlemesi için ayar yaparız. Inıt container içerisinde, bir uygulama çalıştırılır ve bu servisten okey alana kadar bu init container çalışır. ve Okey aldıktan sonra da kapanacak şekilde ayar yapabiliriz. Bu sayede pod oluşturulduğu ilk zaman ilk olarak init container çalışır ve diğer servisi beklemeye başlar. Diğer servis hazır olduğu anda, uygulama kapanır ve init container da kapanır. init container kapatıldığı anda, esas uygulamamızın çalıştığı container ayağa kalkar. Böylece servis hazır olana kadar, uygulamamız beklemiş olur.

Misal, ana uygulamamızın ihtiyacı olan bazı config dosyalarının, son güncel halini ana uygulama başlamadan sisteme çekilmesi gerekiyor. Bu durumda, bu çekme işini de init container ile halleder ve esas uygulama başlamadan bunları sisteme indirebiliriz. vb.

apiVersion: v1
kind: Pod
metadata:
  name: website
spec:
  initContainers:
    - name: clone-repo
      image: alpine/git
      command:
        - git
        - clone
        - --progress
        - https://github.com/peterj/simple-http-page.git
        - /usr/share/nginx/html
      volumeMounts:
        - name: web
          mountPath: '/usr/share/nginx/html'
  containers:
    - name: nginx
      image: nginx
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: web
          mountPath: '/usr/share/nginx/html'
  volumes:
    - name: web
      emptyDir: {}
PreviousKubectl ve VersiyonNextLabel ve Selector

Last updated 3 years ago

Was this helpful?

🍎
❤️
What is the difference between always and on failure for kubernetes restart policy?Stack Overflow
Logo