💻
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
  • Liveness Probe
  • Readiness Probe

Was this helpful?

  1. Kubernetes

Liveness Probe & Readiness Probe

Liveness Probe

Bazı durumlarda, container içerisinde başlatılan uygulama process çalışıyor olsa da, aslında yapması gereken işi yapmıyor olabilir.

Örneğin, bir web sayfası yayınlayan podumuz var. İçerisinde httpd tabanlı bir container çalışıyor. Bu pod başlayınca, container içinde ki, httpd deamon ayağa kalkıyor ve web sitemizi sunmaya başlıyor. Fakat bir zaman sonra bu servis takılmaya başlıyor. Bir hatadan dolayı sayfaları sunmaya devam edemiyor. Ama httpd uygulaması, yani servis ayakta. Servis kapanmadı yada çökmedi. Ama esas yapması gereken iş olan, web sitemizi sunma işini yapmıyor.

Bu ve benzeri durumları yaşadığımız zaman ortamda şöyle bir sıkıntı oluşuyor. Eğer uygulama çalışmıyor olsa, yani uygulama kapansa, kubelet bunu tespit ederek, containerı yeniden başlatarak sorunu çözüyor.

Fakat uygulama ayakta olmasına rağmen, yapması gereken işi yapmıyorsa, kubelet bunu, tespit edemiyor. Dolayısıyla containerı yeniden başlatarak, sorunu çözme mekanizması çalışmıyor. Bu problemi Liveness proble ile çözebiliriz.

  • Kubelet bir containerın, ne zaman yeniden başlatılacağını bilmek için, Liveness probe kullanır.

Örneğin, Liveness Probe bir uygulamanın çalıştığı ancak ilerleme sağlayamadığı, bir kitlenmeyi yakalayabilir. Böyle bir durumda bir containerı yeniden başlatmak, hatalara rağmen uygulamayı, daha kullanılabilir hale getirmeye yardımcı olabilir.

Liveness probe ile biz container içerisinde, bir komut çalıştırarak, ya da http endpointe istek göndererek ya da bir porta tcp connection açarak uygulamanın doğru çalışıp, çalışmadığını kontrol etme imkanına sahip oluyoruz.

Bu sorgulamaların sonucunda, beklediğimiz sonucu alırsak, containerın sağlıklı olduğunu, Eğer cevap beklediğimiz gibi değilse containerın problemli olduğunu tespit edebiliyoruz. Kubelet bu sorgu sonucuna göre aksiyon alabiliyor. Liveness probe tanımlamaları yaml içerisinde LivenessProbe: parametresi altında tanımlanıyor.

Kullanabileceğimiz 3 Tip Probe mevcut;

1 - httpGet

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

Bu probe seçtiğimizde, şunu diyoruz. Localhost 'a "path" parametresi altında belirlediğimiz path'e, "Port" Parametresinde belirlediğimiz porta httpGet isteği gönder. Cevap olarak, 200-400 arasında bir cevap kodu dönerse, yani cevap alabilirse işler yolundadır. Aksi bir cevap dönerse, hata olduğunu anlayıp, containerı restart et. İsteğimize custom bir http headerı ekleyebiliriz.

InıtıalDelaySeconds ve PeriodSeconds parametreleri, şu işe yarıyor; Bir pod oluşturduğumuzda, container çalışır fakat container içerisindeki, uygulama hemen ayağa kalkmayabilir. Ön hazırlıkları yapması gerekebilir. Bir yerden dosya çekmesi gerekebilir. kısacası uygulama container çalıştıktan sonra, hemen hizmet vermeyebilir. Eğer Liveness probe hemen başlatırsak, daha henüz uygulama hazır olmadığı için hata alacaktır. Ve hemen container restart edilecektir. Dolayısıyla daha tam anlamıyla hizmet sunmadan fail edecek ve sürekli restart olacaktır.

Bunu önlemek adına, initialDelaySeconds parametresini kullanıyoruz. Ve liveness probe 'a şunu diyoruz. Container başladıktan sonra, burada belirttiğimiz süre sonuna kadar bekle ardından sağlık kontrolüne başla.

PeriodSeconds ile, bu sağlık kontrolünün kaç saniye aralıklarla yapılacağını belirtiyoruz. Yani container başladı, initialdelaySeconds süresi boyunca bekledi, ardından httpget ile liveness check yapmaya başladı. 1. sorgusunu yaptı cevap olumlu, 2. sorguyu göndermeden Periodseconds da belirlediğimiz süre boyunca bekledi, sonrasında tekrar sorgu yaptı. Bu döngü bu şekilde devam edecek. Sorgular arası kaçar saniye beklemesini istiyorsak, periodSeconds parametresi ile belirtiyoruz.

2 - Exec (Komut yürütme)

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

HTTP uygulamalarımızı httpget ile kontrol edebiliyoruz. Ancak uygulamalarımız http uygulaması değilse, bir konsol uygulaması vb. ise. Bunu httpget ile sorgulamamız mümkün değil.

Bunun yerine, bir script yazar, o script içerisinde uygulamamıza uygu sorgulama neyse, misal bir dosyanın olup, olmadığını kontrol edebiliriz. Ya da bir başka process 'in çalışıp, çalışmadığını kontrol edebiliriz. Uygulamamıza uygun sağlık kontrolünü seçeriz.

Liveness Probe altında httpGet dışında kullanabileceğimiz probe olan EXEC bize bu imkanı verir. Exec ile shell 'de, komut yada uygulama çalıştırırız. Bu uygulama(komut) bize 0 kodu dönerse, yani olumlu bir cevap verirse, sağlıklı olduğunu anlar. Bunun dışında bir cevap dönerse, problemli olarak işaretler ve container 'ı restart eder. Yukarıda ki örnekte exec probe ile bir komut çalıştırıyoruz. cat komutu ile /tmp/healty dosyasını kontrol ediyoruz. Eğer, tmp dizininde böyle bir dosya varsa, bize bu komutun sonucu 0 dönecektir ve olumlu olacaktır. Böyle bir dosya yoksa, exit code 1 olacak. Yani burada bir dosyanın olup, olmadığını kontrol ederek, uygulamanın sağlıklı çalışıp, çalışmadığını kontrol ediyoruz.

3 - TCPSocket

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

Bazen httpget isteği ve komut çalıştırmak, bir şeyin sağlıklı olup, olmadığını anlamamıza yardımcı olmaz.

Misal bir mySQL veritabanı container çalıştırıyoruz. mysql process 3306 portundan erişilebilir. Biz de TCPSocket ile bu porta bir istek gönderip, eğer cevap alırsak uygulamanın düzgün çalıştığını varsayabiliriz. Olumsuz cevap alırsak, porta erişemezsek container restart edilecek.

Readiness Probe

Senaryo ;

3 frontend podumuzu oluşturacak bir deploymentımız, bu podlara dış dünyadan erişilebilmesini sağlayacak Load Balancer tipi bir service mevcut. Biz tüm bunları yaml dosyası arayıcılığıyla oluşturduk ve apply ettik. Ve ortamımız çalışmaya başladı. Load Balancer IP adresi üzerinden kullanıcılar bu frontend podlarımıza erişip, web sitemize gelebiliyorlar.

Şimdi gelin deployment objesinde güncelleme yapalım. Diyelim ki, web sitemizin bulunduğu imajı güncelledik ve deploymentımızı yeniden apply ettik. rolling-update stratejisi ile, podlar sırayla devreden çıkarlıp, yeni podlar devreye alındı.

Burada olanları yakından inceleyelim;

Deployment da yeni bir imaj atadığımız zaman kubernetes hemen bu güncel imaj ile pod oluşturarak, bu yeni podları Load Balancer servisine dahil edecek.

Yani oluşturulup, başlatıldığı anda dış dünyadan bu podlara erişilebilinir olacak. Ya bizim uygulamamız ilk başladığı anda, bir yerlere bağlanıp, bazı dosyaları çekiyor ve sonrasında web sitemizi sunmaya başlıyorsa, Yada başka bir nedenden dolayı container başlatılır, başlatılmaz bu uygulama hizmet veremiyorsa, aradan belirli bir zaman geçip, bazı işlemler yapması gerekiyorsa, Eğer durum bu ise, bu podları oluşturulduğumuz anda, bu podlar LoadBalancer servisinden trafik almaya başladığı için problem çıkacaktır.

Yani pod ayakta içindeki uygulama çalışıyor ancak, web sitemizi sunmaya hazır değil. Dolayısıyla bu pod, LoadBalancer servisine eklenmek için hazır değil. Peki bu pod 'un Load Balancer servisinden trafik almaya hazır olduğunu nasıl anlayacağız? Burada da, yardımımıza Readiness probe yetişiyor.

Kubelet, bir containerın trafiği kabul etmeye hazır olduğunu bilmek için, readiness probeları kullanır. Bir pod, tüm containerlar hazır olduğunda, hazır kabul edilir. Readiness probe sayesinde, bir pod hazır olana kadar, service arkasına eklenmez.

Readiness probelar, aynen liveness probelar gibi oluşturulur. httpGet, Exec, TCPSocket olarak kurgulanabilir.

Biz bir readiness check tanımlarız. Eğer bu readiness check olumlu sonuç dönüyorsa, Pod Service altına eklenir ve trafik alır. Eğer readiness check fail ediyorsa, bu pod service 'den çıkarılır.

Örneğimize dönersek, yeni imajı tanımladık ve yeni podlar oluşturuldu. Podlar çalışmaya başladı. Ama bu noktada load balancer service altına hemen eklenmedi. Podlar içerisinde readiness check mekanizması çalışmaya başladı initialdelayseconds süresi kadar bekledi, sonra tanımladığımız probe ile kontrolünü yaptı. Olumlu cevap aldığı anda, bu pod service arkasına eklenir ve trafik almaya başlar.

Readiness Check periodSeconds ile belirlenen süre kadar, sürede bir bu kontrolünü yapmaya devam eder. Fail edene kadar service arkasında trafik alır. Eğer fail ederse, pod service endpoint listesinden çıkarılır.

Eski podları direkt kapatmak yerine, kullanıcılara hata göstermemek için. Bir pod terminate edileceği zaman. Bu poda yeni trafik gelmemesi için pod service arkasından çıkarılır. Service ile bağlantısı kesilir. Böylece trafik almaz. Fakat kubernetes hemen bu podu kapatmaz. Çünkü yeni trafik gelmese bile, bu pod halen eski istekleri işlemeye devam ediyor olabilir. Bu nedenle, bu işlemleri beklemesi gerekebilir.

Pod tanımlarında, terminationGracePeriodSeconds şeklinde bir parametre bulunur. Ve varsayılan olarak değeri 30 saniyedir. Aksini belirtmediğimiz sürece bu değer kullanılır. Biz veya kubelet podu terminate istediğimiz zaman podun içerisinde çalışan master process ine hemen sigkill sinyali gönderip hemen öldürmez. Bunun yerine sigturn sinyali gönderir yani, yaptığın bir işlem varsa düzgün bir şekilde tamamla, bitince de kendini kapat sinyalini gönderir. Eğer process bu sinyali aldığında eğer ortasında olduğu bir iş varsa, onu yapmayı bırakmaz. O işlemi tamamlar ve bittikten sonra tüm bağlantıları düzgün bir şekilde kapatıp sonrasında da process de kapatılır.

terminationGracePeriodSeconds süresi, bu container a düzgün şekilde kendisini kapatabilmesi için atadığımız bir süredir. Eğer process bu süre içerisinde düzgün bir şekilde kapatılırsa sıkıntı olmayacaktır. Fakat kapanmazsa da, bu süre sonunda sigkill sinyali gönderilip, zorla kapatılır. Dolayısıyla uygulamamızın ne kadar süre içerisinde kapanabildiğini bilmemiz o na göre de terminationGracePeriodSeconds süresini düzenlememiz gerekebilir.

Readiness Aşamaları,

1 - Deployment dosyası içerisinde imajımızı güncelledik.

2- Yeni imajda, yeni bir pod oluşturuldu.

3- Yeni pod çalışmaya başladı.

4- Readiness check mekanizması çalışmaya başladı. initialdelayseconds süresi kadar bekledi ve ardından ilk kontrolünü yaptı.

5- Kontrol sonucu olumlu olduğu anda, yeni pod service altına eklendi.

6- Eski pod henüz kapatılmadı, Eğer işlemesi gereken istekler varsa, işlemeye devam ediyor. Ve yeni istekler gelmemesi için service altından çıkarıldı.

7- Eski podun kendini düzgün kapatabilmesi için, sigterm sinyali gönderildi.

8- Eski pod üzerindeki işlemleri tamamladıktan sonra, kendini kapadı.

Örnek Readiness Probe Yaml içeriği;

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
  labels:
    team: development
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: frontend
        image: blue
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /healthcheck
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /ready
            port: 80
          initialDelaySeconds: 20
          periodSeconds: 3
---
apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  selector:
    app: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Readiness ve Liveness Probe 'lar aynı anda kullanılabilir.

PreviousServiceNextResource Limits

Last updated 3 years ago

Was this helpful?

🍎
🛠️
Kubernetes best practices: terminating with grace | Google Cloud BlogGoogle Cloud Blog
Logo