<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>სტებაკოვი · SRE / DevOps</title>
    <link>https://stebas.com/ka/</link>
    <description>ჩანაწერები პროდაქშენიდან და სახლის ლაბორატორიიდან: განახლებები, მიგრაციები, ინციდენტები.</description>
    <language>ka</language>
    <item>
      <title>RDS კავშირებზე უარს ამბობდა 10% CPU-ზე: ნაგულისხმევი პულები, გამრავლებული რეპლიკებზე</title>
      <link>https://stebas.com/ka/posts/rds-connection-ceiling-npgsql-pools/</link>
      <guid>https://stebas.com/ka/posts/rds-connection-ceiling-npgsql-pools/</guid>
      <pubDate>Mon, 12 Oct 2026 00:00:00 GMT</pubDate>
      <description>დატვირთვის ტესტები ~420 კავშირის ბრტყელ პლატოზე ჩერდებოდა და „უფრო დიდ ბაზას" ითხოვდნენ. ნამდვილი ჭერი იყო max_connections Npgsql-ის ნაგულისხმევი პულების წინააღმდეგ.</description>
    </item>
    <item>
      <title>Calico Ready-ში იყო შეცდომების გარეშე, ყოველი ახალი პოდი კი ნახევარი წუთი მიუწვდომელი იყო</title>
      <link>https://stebas.com/ka/posts/calico-xdp-resync-new-pod-blackhole/</link>
      <guid>https://stebas.com/ka/posts/calico-xdp-resync-new-pod-blackhole/</guid>
      <pubDate>Sat, 10 Oct 2026 00:00:00 GMT</pubDate>
      <description>Calico-ს განახლების შემდეგ ახალი პოდები 15–42 წამი შავ ხვრელში იყვნენ. Felix XDP resync-ის ციკლში იყო ჩარჩენილი, რომელიც მხოლოდ ნოდებს შორის ახალი პოდების ტესტმა აჩვენა.</description>
    </item>
    <item>
      <title>Kubernetes 1.32-დან 1.37-მდე ერთ დღეში, ხუთი ჰოპი, იმ kubespray-ის გარეშე, რომლითაც კლასტერი აიწყო</title>
      <link>https://stebas.com/ka/posts/kubernetes-five-hop-upgrade-without-kubespray/</link>
      <guid>https://stebas.com/ka/posts/kubernetes-five-hop-upgrade-without-kubespray/</guid>
      <pubDate>Sat, 10 Oct 2026 00:00:00 GMT</pubDate>
      <description>EOL ვერსიაზე მყოფი bare-metal კლასტერი, დაკარგული kubespray ინვენტარი და ბინარები პაკეტების მენეჯერის გარეთ. როგორ გავიდა kubeadm-ის ხუთი ჰოპი ერთ დღეში და ხაფანგები, რომლებიც არც ერთ გეგმაში არ იყო.</description>
    </item>
    <item>
      <title>ერთი წუთი მუშაობდა, მერე ტაიმაუტები: MetalLB L2 და kube-proxy ipvs strictARP-ის გარეშე</title>
      <link>https://stebas.com/ka/posts/metallb-l2-ipvs-strictarp/</link>
      <guid>https://stebas.com/ka/posts/metallb-l2-ipvs-strictarp/</guid>
      <pubDate>Sat, 10 Oct 2026 00:00:00 GMT</pubDate>
      <description>ჰოსტების ახალ LoadBalancer IP-ზე გადაყვანა ცოტა ხანს მუშაობდა, მერე გარე ბალანსერმა L4 ტაიმაუტები დაინახა. ერთსა და იმავე IP-ზე ARP-ს ყველა ნოდი პასუხობდა.</description>
    </item>
    <item>
      <title>სერტიფიკატებს ვადა გრაფიკით გაუვიდა. ალერტი ერთი კვირა ყვიროდა — სიცარიელეში</title>
      <link>https://stebas.com/ka/posts/kubeadm-certs-expired-alert-into-null/</link>
      <guid>https://stebas.com/ka/posts/kubeadm-certs-expired-alert-into-null/</guid>
      <pubDate>Fri, 09 Oct 2026 00:00:00 GMT</pubDate>
      <description>kubeadm კლასტერმა control plane დაკარგა ინსტალაციიდან ზუსტად ერთი წლის შემდეგ. ალერტი შვიდი დღე იწვოდა, მაგრამ Alertmanager-ს მხოლოდ null მიმღები ჰქონდა.</description>
    </item>
    <item>
      <title>ალერტი ჩაირთო და ვერავინ დაინახა: cluster ლეიბლი აგრეგაციაში დაიკარგა</title>
      <link>https://stebas.com/ka/posts/alert-lost-cluster-label/</link>
      <guid>https://stebas.com/ka/posts/alert-lost-cluster-label/</guid>
      <pubDate>Wed, 07 Oct 2026 00:00:00 GMT</pubDate>
      <description>ნოდი ოთხი საათი 90–98% CPU-ზე იჯდა და OOM kill-ით დასრულდა. CPU ალერტი ჩაირთო, მაგრამ avg by(instance)-მა ის ლეიბლი გადააგდო, რომლითაც ყველა მარშრუტი და დაშბორდი ირჩევდა.</description>
    </item>
    <item>
      <title>Kubernetes 1.33 → 1.36 და Calico → Cilium ერთ დღეში</title>
      <link>https://stebas.com/ka/posts/k8s-136-cilium-in-one-day/</link>
      <guid>https://stebas.com/ka/posts/k8s-136-cilium-in-one-day/</guid>
      <pubDate>Wed, 30 Sep 2026 00:00:00 GMT</pubDate>
      <description>რეპეტიცია სახლის ლაბორატორიაში: Kubernetes-ის სამი ნაბიჯი, CNI-ის შეცვლა Cilium-ით kube-proxy-ის გარეშე და ingress-nginx-ის ნაცვლად Gateway API — რატომ აჯობა კონტროლირებადმა big-bang-მა ცოცხალ მიგრაციას და რა ხაფანგები უნდა იცოდეთ.</description>
    </item>
    <item>
      <title>საბრძოლო სერტიფიკატს ვადა გაუვიდა და არავინ შეამჩნია: გარე პროქსიმ ავარია საკუთარი თავით დაფარა</title>
      <link>https://stebas.com/ka/posts/expired-tls-hidden-by-front/</link>
      <guid>https://stebas.com/ka/posts/expired-tls-hidden-by-front/</guid>
      <pubDate>Thu, 17 Sep 2026 00:00:00 GMT</pubDate>
      <description>ყველა საჯარო ჰოსტი 200-ს აბრუნებდა, კლასტერი კი ვადაგასულ wildcard-ს აძლევდა. საკუთარი TLS-ის მქონე პროქსიმ ავარია დამალა; ნამდვილი მიგნება ვადის ალერტის არარსებობა იყო.</description>
    </item>
    <item>
      <title>multipathd-მა Longhorn-ის ტომი მიითვისა: „mount point busy“, თუმცა არაფერია დამონტაჟებული</title>
      <link>https://stebas.com/ka/posts/multipathd-hijacks-longhorn/</link>
      <guid>https://stebas.com/ka/posts/multipathd-hijacks-longhorn/</guid>
      <pubDate>Thu, 17 Sep 2026 00:00:00 GMT</pubDate>
      <description>პოდი ხუთი დღე Init-ში იდგა, 2413 მონტაჟის მცდელობა, სრულმა რებუტმა არ უშველა. multipathd-მა Longhorn-ის iSCSI მოწყობილობაზე რუკა ააგო და ღიად ეჭირა.</description>
    </item>
    <item>
      <title>რებალანსის შტორმი ჩვეულებრივი დეპლოი აღმოჩნდა: ზღვარი, რომელიც ჯგუფთან ერთად იზრდება</title>
      <link>https://stebas.com/ka/posts/rebalance-storm-deploy-signature/</link>
      <guid>https://stebas.com/ka/posts/rebalance-storm-deploy-signature/</guid>
      <pubDate>Wed, 16 Sep 2026 00:00:00 GMT</pubDate>
      <description>Kafka-ს რებალანსის ალერტი ყოველ რელიზზე საათში 60-ზე ირთვებოდა. მეტრიკა 40 კონსიუმერზე ჯამდებოდა და მოცურავე საათით საშუალოვდებოდა — ალერტი წარსულს აღწერდა.</description>
    </item>
    <item>
      <title>Argo CD აჩვენებდა Synced-ს, API სერვერმა კი ჩუმად გადააგდო ჩემი შესწორება</title>
      <link>https://stebas.com/ka/posts/argocd-synced-but-field-pruned/</link>
      <guid>https://stebas.com/ka/posts/argocd-synced-but-field-pruned/</guid>
      <pubDate>Tue, 15 Sep 2026 00:00:00 GMT</pubDate>
      <description>თვეობით არ იყო მეტრიკები, შესწორება უკვე git-ში იდო და სტატუსი მწვანე Synced იყო. ველი CRD-ის სქემაში არ არსებობდა, API სერვერმა მოჭრა და არავინ იჩივლა.</description>
    </item>
    <item>
      <title>Liveness პრობა, მიბმული სხვის ქსელზე: 330 რესტარტი, რომლებმაც არაფერი შეაკეთეს</title>
      <link>https://stebas.com/ka/posts/liveness-probe-external-dependency/</link>
      <guid>https://stebas.com/ka/posts/liveness-probe-external-dependency/</guid>
      <pubDate>Tue, 15 Sep 2026 00:00:00 GMT</pubDate>
      <description>cloudflared-ის ორი იდენტური რეპლიკა — 330 და 13 რესტარტი. Liveness ამოწმებდა გვირაბს edge-მდე, ამიტომ აპლინკის ყოველი შეფერხება SIGKILL-ად იქცეოდა.</description>
    </item>
    <item>
      <title>ჩატვირთვის ეკრანი retry-ციკლი იყო და არა გაჭედვა — გადატვირთვა საჭირო არ ყოფილა</title>
      <link>https://stebas.com/ka/posts/retry-loop-not-a-hang/</link>
      <guid>https://stebas.com/ka/posts/retry-loop-not-a-hang/</guid>
      <pubDate>Mon, 14 Sep 2026 00:00:00 GMT</pubDate>
      <description>თამაში ჩემს Linux-კომპიუტერზე ჩატვირთვის ეკრანზე იჭედებოდა, ცნობილი წამალი კი სრული გადატვირთვა იყო. /proc-ის მთვლელების ხუთმა წამმა აჩვენა ციკლი, რომელიც ერთი SIGTERM-ით სრულდება.</description>
    </item>
    <item>
      <title>ალერტინგის სამი გაუმართაობა ერთი ფესვიდან: სახელი იქ, სადაც ID უნდა ყოფილიყო</title>
      <link>https://stebas.com/ka/posts/mutable-name-vs-contract/</link>
      <guid>https://stebas.com/ka/posts/mutable-name-vs-contract/</guid>
      <pubDate>Mon, 07 Sep 2026 00:00:00 GMT</pubDate>
      <description>ვიღაცამ Slack-ის არხს სახელი გადაარქვა და პროდაქშენ-სისტემის ალერტების მიწოდება ჩუმად მოკვდა. ეს იგივე იდენტიფიკატორზე მესამე გაუმართაობა იყო.</description>
    </item>
    <item>
      <title>Kafka 94 %-ით სავსე დისკზე, 17 საათის მარაგი და retention, რომელიც ორჯერ მეტს ინახავდა</title>
      <link>https://stebas.com/ka/posts/kafka-retention-segment-roll/</link>
      <guid>https://stebas.com/ka/posts/kafka-retention-segment-roll/</guid>
      <pubDate>Sun, 06 Sep 2026 00:00:00 GMT</pubDate>
      <description>ტრაფიკი 150-ჯერ გაიზარდა, ტომები კი არავის გადაუხედავს. უარესი: სეგმენტების ნაგულისხმევი როლინგის დროს 7-დღიანი retention სინამდვილეში 7–14 დღეს ნიშნავდა.</description>
    </item>
    <item>
      <title>Basic auth გაქრა 80-ე პორტზე Ingress-იდან Gateway API-ზე გადასვლის შემდეგ</title>
      <link>https://stebas.com/ka/posts/gateway-api-policy-per-listener/</link>
      <guid>https://stebas.com/ka/posts/gateway-api-policy-per-listener/</guid>
      <pubDate>Tue, 01 Sep 2026 00:00:00 GMT</pubDate>
      <description>ყველა სტატუსი მწვანე იყო, ჩემი curl 401-ს აბრუნებდა. WordPress-ის შესვლა კი ყველასთვის ღია იყო: Gateway API პოლიტიკას ერთ listener-ს აბამს, Ingress-ის ანოტაციები კი ყველა პორტს ფარავდა.</description>
    </item>
    <item>
      <title>ექვსი საათი NotReady-ში, ნოდა კი მთელი ამ დროის განმავლობაში ცოცხალი იყო</title>
      <link>https://stebas.com/ka/posts/notready-was-memory-thrashing/</link>
      <guid>https://stebas.com/ka/posts/notready-was-memory-thrashing/</guid>
      <pubDate>Mon, 31 Aug 2026 00:00:00 GMT</pubDate>
      <description>ყველა სიგნალი ამბობდა, რომ ნოდა მკვდარია. სინამდვილეში მეხსიერება აკლდა, ხოლო აშკარა გამოსავალი — ნოდის წაშლა და ტომის იძულებითი მოხსნა — ერთი ბრძანებით იყო დაშორებული ბაზის დაზიანებისგან.</description>
    </item>
    <item>
      <title>ვარსკვლავი Vault-ის გზის შუაში wildcard არ არის</title>
      <link>https://stebas.com/ka/posts/vault-acl-mid-path-glob/</link>
      <guid>https://stebas.com/ka/posts/vault-acl-mid-path-glob/</guid>
      <pubDate>Mon, 31 Aug 2026 00:00:00 GMT</pubDate>
      <description>ვადაგასულმა ტოკენმა საიდუმლოებების ოპერატორი გააჩერა. მისმა ხელახლა გაცემამ უფრო ძველი ბაგი გამოავლინა: Vault-ის 27 პოლიტიკა * სიმბოლოთი გზის შუაში ჩუმად კრძალავდა იმას, რასაც აცხადებდა.</description>
    </item>
    <item>
      <title>Postgres-ის რეპლიკა 23 საათი pg_rewind-ის ციკლში ტრიალებდა: ხელახლა შექმენით და ნუ შეაკეთებთ</title>
      <link>https://stebas.com/ka/posts/cnpg-replica-pg-rewind-loop/</link>
      <guid>https://stebas.com/ka/posts/cnpg-replica-pg-rewind-loop/</guid>
      <pubDate>Fri, 28 Aug 2026 00:00:00 GMT</pubDate>
      <description>failover-ის შემდეგ CloudNativePG-ის რეპლიკამ rewind ვერ გააკეთა: მისი WAL-სეგმენტები ნულოვანი ზომის იყო, მონაცემთა კატალოგი კი primary-ზე ათჯერ პატარა. 23 საათი ვერავინ შეამჩნია, რადგან ოპერატორის მეტრიკები არ გროვდებოდა.</description>
    </item>
    <item>
      <title>Error budget VictoriaMetrics-ში: recording rules, burn-rate ალერტები და ერთი პატიოსანი პანელი</title>
      <link>https://stebas.com/ka/posts/error-budget-burn-rate-alerts/</link>
      <guid>https://stebas.com/ka/posts/error-budget-burn-rate-alerts/</guid>
      <pubDate>Wed, 26 Aug 2026 00:00:00 GMT</pubDate>
      <description>როგორ ავაწყეთ error budget პირველი დონის სერვისებისთვის უკვე არსებული მეტრიკებიდან: SLO-მიზნები სერვისების მიხედვით, multi-window burn-rate ალერტები, რიგი Grafana-ში — და რატომ არ იყო უარყოფითი ბიუჯეტი გაშვებისთანავე ინციდენტი.</description>
    </item>
    <item>
      <title>ერთი p99 ალერტი, ხუთი ნელი მარშრუტი, ხუთი სხვადასხვა მიზეზი</title>
      <link>https://stebas.com/ka/posts/latency-triage-per-route/</link>
      <guid>https://stebas.com/ka/posts/latency-triage-per-route/</guid>
      <pubDate>Wed, 26 Aug 2026 00:00:00 GMT</pubDate>
      <description>სერვისის დონის ლატენტობის ალერტი არც ერთ endpoint-ს არ ასახელებდა. მარშრუტების მიხედვით დაყოფამ აჩვენა გარე შლუზი, captcha-ს შემოწმება, პროვაიდერის გამოძახება — და გაზომვის ხაფანგები, რომლებიც არასწორი გზით წაგვიყვანდა.</description>
    </item>
    <item>
      <title>პროდაქშენის Postgres-ის გადატანა RDS Multi-AZ instance-დან Multi-AZ DB cluster-ზე</title>
      <link>https://stebas.com/ka/posts/rds-instance-to-multi-az-cluster-cutover/</link>
      <guid>https://stebas.com/ka/posts/rds-instance-to-multi-az-cluster-cutover/</guid>
      <pubDate>Mon, 24 Aug 2026 00:00:00 GMT</pubDate>
      <description>დაგეგმილი cutover თითქმის მონაცემების დაკარგვის გარეშე — და სამი ხაფანგი: „ტექსამუშაოები“, რომლებმაც ჩაწერა ვერ შეაჩერეს, პაროლები, რომელთა კოპირებასაც RDS არ იძლევა, და დამპი 25 წუთში VPN-ით 31 წამის წინააღმდეგ VPC-ში.</description>
    </item>
    <item>
      <title>ლაგი ნულზე ჩამოვიდა, მაგრამ არაფერი გამოსწორებულა: Kafka-ს გაჭედილი კონსიუმერი, დამალული group.id-ის გადარქმევით</title>
      <link>https://stebas.com/ka/posts/kafka-consumer-stall-hidden-by-group-rename/</link>
      <guid>https://stebas.com/ka/posts/kafka-consumer-stall-hidden-by-group-rename/</guid>
      <pubDate>Fri, 21 Aug 2026 00:00:00 GMT</pubDate>
      <description>კონსიუმერის ლაგი ხუთ დღეს იზრდებოდა, შემდეგ ნულზე ჩამოვიდა და იქ დარჩა. თითქოს თავისით გამოსწორდა. სინამდვილეში კონსიუმერი გაჭედილი იყო, მეტრიკა გაქრა, ალერტი კი თავისით დაიხურა.</description>
    </item>
    <item>
      <title>Python-ის მეხსიერების გაჟონვის პროფილირება პროდაქშენზე memray-ით — და ავარია, რომელიც გზაში მოვაწყვეთ</title>
      <link>https://stebas.com/ka/posts/python-memory-leak-memray-in-production/</link>
      <guid>https://stebas.com/ka/posts/python-memory-leak-memray-in-production/</guid>
      <pubDate>Mon, 17 Aug 2026 00:00:00 GMT</pubDate>
      <description>ბექენდი ყოველ 10–15 საათში OOM-ით ეცემოდა. ცოცხალ პოდზე memray-ის საათობრივმა ანაბეჭდებმა გაჟონვა ბიბლიოთეკის middleware-ში იპოვა და არა აპლიკაციის კოდში — მას შემდეგ, რაც პირველმა მცდელობამ პროდაქშენი შვიდი წუთით გათიშა.</description>
    </item>
    <item>
      <title>საწარმოო კლასტერის გადატანა Longhorn-იდან LINSTOR-ზე — და მოლოდინი, რომელიც არ ახდა</title>
      <link>https://stebas.com/ka/posts/longhorn-to-linstor-migration/</link>
      <guid>https://stebas.com/ka/posts/longhorn-to-linstor-migration/</guid>
      <pubDate>Sun, 16 Aug 2026 00:00:00 GMT</pubDate>
      <description>რატომ შევცვალეთ Longhorn LINSTOR/DRBD-ით self-managed კლასტერზე, როგორ გადავიდა თითოეული დატვირთვა თავისი გზით და რა წავიდა გზაში ცუდად.</description>
    </item>
    <item>
      <title>ingress-nginx-დან Envoy Gateway-ზე დაუნთაიმის გარეშე: 27 Ingress, 39 HTTPRoute</title>
      <link>https://stebas.com/ka/posts/ingress-nginx-to-envoy-gateway/</link>
      <guid>https://stebas.com/ka/posts/ingress-nginx-to-envoy-gateway/</guid>
      <pubDate>Sat, 15 Aug 2026 00:00:00 GMT</pubDate>
      <description>ingress-nginx გადამდგარია და Kubernetes-ის განახლებებს ბლოკავს. როგორ გადავიყვანეთ 16 საჯარო ჰოსტი Envoy Gateway-ზე: ახალი შესასვლელი ძველის გვერდით ავამუშავეთ და ბოლოს მხოლოდ მისამართი შევცვალეთ.</description>
    </item>
    <item>
      <title>CloudNativePG-ის გადაყვანა Barman Cloud პლაგინზე არქივის გაწყვეტის გარეშე</title>
      <link>https://stebas.com/ka/posts/cnpg-barman-cloud-plugin-switchover/</link>
      <guid>https://stebas.com/ka/posts/cnpg-barman-cloud-plugin-switchover/</guid>
      <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
      <description>CNPG barmanObjectStore-ის ჩაშენებულ მხარდაჭერას აუქმებს. გადართვას ვალიდური შუალედური მდგომარეობა არ აქვს, ბაზას არც ერთი საბაზისო ბექაპი არ ჰქონდა, ერთი გზა კი წყვეტს, იმუშავებს თუ არა point-in-time recovery.</description>
    </item>
    <item>
      <title>ოთხი შემოწმება, რომელიც ტყუოდა, სანამ სისტემა ჯანსაღი იყო</title>
      <link>https://stebas.com/ka/posts/four-checks-that-lied/</link>
      <guid>https://stebas.com/ka/posts/four-checks-that-lied/</guid>
      <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
      <description>პლატფორმის მიგრაციების ერთ დღეში ოთხი შემოწმება შეცდომას აცხადებდა, თუმცა ყველაფერი რიგზე იყო. როცა ერთი სიგნალი ყველა დანარჩენს ეწინააღმდეგება, პირველ რიგში თავად სიგნალს ეჭვობდეთ.</description>
    </item>
    <item>
      <title>ალერტები, რომლებიც ვერ ამოქმედდებიან: ბრმა ServiceMonitor და მკვდარი მიწოდების არხი</title>
      <link>https://stebas.com/ka/posts/alerts-that-cannot-fire/</link>
      <guid>https://stebas.com/ka/posts/alerts-that-cannot-fire/</guid>
      <pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate>
      <description>Vault-ის პირი 32 საათი sealed იყო, საიდუმლოებები კი კვირაზე მეტი არ სინქრონიზდებოდა — რეპოზიტორიაში VaultSealed ალერტით და ჯანმრთელი Alertmanager-ით. ინციდენტი ორმა დამოუკიდებელმა შეფერხებამ დამალა.</description>
    </item>
    <item>
      <title>„ბირთვების დრეიფი“ აპტაიმის დრეიფი აღმოჩნდა: პატჩები დგებოდა, გადატვირთვა — არა</title>
      <link>https://stebas.com/ka/posts/kernel-drift-was-uptime-drift/</link>
      <guid>https://stebas.com/ka/posts/kernel-drift-was-uptime-drift/</guid>
      <pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate>
      <description>შვიდ ნოდაზე სამი სხვადასხვა ბირთვი დაუსრულებელ პატჩების ტალღებს ჰგავდა და გამოძიება ცრუ კვალზე წაიყვანა. პატჩები ყველა ნოდაზე ერთნაირი იყო, განსხვავდებოდა მხოლოდ აპტაიმი.</description>
    </item>
    <item>
      <title>kubectl patch --type merge-მა CoreDNS წაშალა, ყველა შემოწმება კი მწვანე დარჩა</title>
      <link>https://stebas.com/ka/posts/kubectl-merge-patch-wiped-coredns/</link>
      <guid>https://stebas.com/ka/posts/kubectl-merge-patch-wiped-coredns/</guid>
      <pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate>
      <description>იმიჯის ერთხაზიანმა განახლებამ კონტეინერის მთელი სპეციფიკაცია შეცვალა. CoreDNS-მა კონფიგი დაკარგა, ჩუმად whoami პლაგინზე გადავიდა და ყველაფერს NOERROR-ით პასუხობდა პასუხის გარეშე.</description>
    </item>
    <item>
      <title>MetalLB-ის შეცვლა Cilium LB IPAM-ით ისე, რომ არც ერთი მოთხოვნა არ დაკარგულა</title>
      <link>https://stebas.com/ka/posts/metallb-to-cilium-lb-ipam/</link>
      <guid>https://stebas.com/ka/posts/metallb-to-cilium-lb-ipam/</guid>
      <pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate>
      <description>კლასტერში მხოლოდ ერთი LoadBalancer IP იყო და ყველა მარშრუტი მასზე იყო დამოკიდებული. როგორ გადავეცი ის MetalLB-დან Cilium-ს შეცდომების გარეშე — ორივე კონტროლერს ერთდროულად ვამუშავებდი.</description>
    </item>
    <item>
      <title>Vault-ის გადაყვანა Shamir-დან transit auto-unseal-ზე და ოთხი ხაფანგი გზაზე</title>
      <link>https://stebas.com/ka/posts/vault-transit-auto-unseal/</link>
      <guid>https://stebas.com/ka/posts/vault-transit-auto-unseal/</guid>
      <pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate>
      <description>Vault-ის პოდის ყოველი გადატვირთვა დალუქული საცავით და გაყინული საიდუმლოებების სინქრონიზაციით სრულდებოდა. როგორ დავამატეთ transit პროვაიდერი, გადავიყვანეთ სამნოდიანი raft კლასტერი და სად წავიბორძიკეთ.</description>
    </item>
    <item>
      <title>Vault თავისით ილუქებოდა. მიზეზი კლასტერის ქვემოთ VM-ის 15-წუთიანი გაყინვა იყო</title>
      <link>https://stebas.com/ka/posts/vm-backup-freeze-cascade/</link>
      <guid>https://stebas.com/ka/posts/vm-backup-freeze-cascade/</guid>
      <pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate>
      <description>Vault-ის ოთხი seal სამ კვირაში, თითოეული ცალკე ინციდენტად განიხილებოდა. journald-ის პაუზების ანალიზმა აჩვენა, რომ ჰიპერვიზორი ბექაპისას VM-ს ყინავს, Longhorn კი ამას კასკადად აქცევს.</description>
    </item>
    <item>
      <title>GitLab-ის განახლება და ორი სიგნალი, რომლებიც ტყუოდნენ</title>
      <link>https://stebas.com/ka/posts/gitlab-upgrade-signals-that-lie/</link>
      <guid>https://stebas.com/ka/posts/gitlab-upgrade-signals-that-lie/</guid>
      <pubDate>Wed, 12 Aug 2026 00:00:00 GMT</pubDate>
      <description>self-hosted GitLab-ის ჩვეულებრივი მინორული განახლება Docker-ში. წინასწარმა შემოწმებამ 32 დაუსრულებელი მიგრაცია დაითვალა, კონტეინერი კი healthy გახდა ისე, რომ არაფერს ემსახურებოდა.</description>
    </item>
    <item>
      <title>როგორ განვაახლოთ OS შვიდ Kubernetes ნოდაზე ისე, რომ ვერავინ შეამჩნიოს</title>
      <link>https://stebas.com/ka/posts/rolling-os-update-seven-nodes/</link>
      <guid>https://stebas.com/ka/posts/rolling-os-update-seven-nodes/</guid>
      <pubDate>Wed, 12 Aug 2026 00:00:00 GMT</pubDate>
      <description>Ubuntu-ს რიგრიგობითი განახლება კლასტერში, რომელიც საკუთარ მდგომარეობას თავად ინახავს. წინასწარმა შემოწმებებმა საშიში სამუშაო მოსაწყენად აქცია, ტემპს კი Longhorn კარნახობდა.</description>
    </item>
    <item>
      <title>ერთმა დავიწყებულმა DHCP ოფციამ მთელი Kubernetes კლასტერი გათიშა</title>
      <link>https://stebas.com/ka/posts/stale-dhcp-route-killed-cluster/</link>
      <guid>https://stebas.com/ka/posts/stale-dhcp-route-killed-cluster/</guid>
      <pubDate>Mon, 10 Aug 2026 00:00:00 GMT</pubDate>
      <description>ჰოსტის გადატვირთვის შემდეგ ორმოცდაათამდე პოდი CrashLoop-ში წავიდა, თუმცა ყველა ნოდა Ready იყო. მიზეზი დავიწყებული DHCP classless routes ოფცია იყო, რომელმაც ნაგულისხმევი შლუზი ჩუმად წაშალა.</description>
    </item>
    <item>
      <title>დამერჯილი, დასინქრონებული, მიმაგრებული — და მაინც არ ალერტავს: vmalert hot reload-ის გარეშე</title>
      <link>https://stebas.com/ka/posts/vmalert-rules-no-hot-reload/</link>
      <guid>https://stebas.com/ka/posts/vmalert-rules-no-hot-reload/</guid>
      <pubDate>Fri, 07 Aug 2026 00:00:00 GMT</pubDate>
      <description>Kafka-ს ახალმა წესებმა Git-ისა და Argo CD-ის გავლით ConfigMap-მდე მიაღწიეს, მაგრამ vmalert-მა მათი შეფასება ასე და ვერ დაიწყო. GitOps კონვეიერი ბოლო ნაბიჯზე გაწყდა.</description>
    </item>
    <item>
      <title>Grafana-ს პანელი, რომელიც გეუბნება, როდის დაეცემა პოდი OOM-ით</title>
      <link>https://stebas.com/ka/posts/grafana-capacity-forecast-dashboard/</link>
      <guid>https://stebas.com/ka/posts/grafana-capacity-forecast-dashboard/</guid>
      <pubDate>Thu, 06 Aug 2026 00:00:00 GMT</pubDate>
      <description>როგორ ვაქციოთ მეხსიერების ტრენდი ETA-დ OOM-მდე და დისკის შევსებამდე PromQL-ით, ორი ხარვეზი, რის გამოც პანელი ცრუობდა, და გაჟონვა, რომელიც პირველივე დღეს დაიჭირა.</description>
    </item>
    <item>
      <title>ONLINE_UNCERTAIN: როცა MySQL ოპერატორი და ბაზა ვერ თანხმდებიან</title>
      <link>https://stebas.com/ka/posts/innodb-online-uncertain-rescan/</link>
      <guid>https://stebas.com/ka/posts/innodb-online-uncertain-rescan/</guid>
      <pubDate>Thu, 06 Aug 2026 00:00:00 GMT</pubDate>
      <description>Router ციმციმებს, ოპერატორი ორი დღეა ბლოკირებაშია, CRD 2/3-ზე გაიყინა — თან InnoDB Cluster-ის სამივე წევრი ჯანმრთელია. გამოსავალი მეტამონაცემების ერთი rescan იყო.</description>
    </item>
    <item>
      <title>Vault Secrets Operator seal-ის შემდეგ გაჩუმდა — და გადატვირთვამ ვერ გააღვიძა</title>
      <link>https://stebas.com/ka/posts/vso-stuck-after-vault-seal/</link>
      <guid>https://stebas.com/ka/posts/vso-stuck-after-vault-seal/</guid>
      <pubDate>Thu, 06 Aug 2026 00:00:00 GMT</pubDate>
      <description>43-დან 38 VaultStaticSecret ორი დღე გაყინული შეცდომით იდგა. Vault-ის unseal-მა და ოპერატორის გადატვირთვამ არაფერი მისცა; spec-ის ერთი ველის შეცვლამ უშველა.</description>
    </item>
    <item>
      <title>WordPress-ში შესვლის მარყუჟი, რომელიც მხოლოდ ზოგჯერ ხდებოდა</title>
      <link>https://stebas.com/ka/posts/wordpress-redirect-loop-per-pod-salts/</link>
      <guid>https://stebas.com/ka/posts/wordpress-redirect-loop-per-pod-salts/</guid>
      <pubDate>Thu, 06 Aug 2026 00:00:00 GMT</pubDate>
      <description>wp-admin შესვლის გვერდზე reauth=1-ით აბრუნებდა, მაგრამ არა ყოველთვის. მიზეზი იყო ყოველ პოდში გენერირებული შემთხვევითი auth salt-ები sticky სესიების გარეშე ბალანსერის უკან.</description>
    </item>
    <item>
      <title>სამი ინციდენტი, რომელიც ერთი აღმოჩნდა: კონფიგში ჩაწერილი მონაცემთა ბაზის IP</title>
      <link>https://stebas.com/ka/posts/dbaas-master-ip-change/</link>
      <guid>https://stebas.com/ka/posts/dbaas-master-ip-change/</guid>
      <pubDate>Fri, 31 Jul 2026 00:00:00 GMT</pubDate>
      <description>500 შესვლისას, CrashLoopBackOff-ში მყოფი ბექენდები და გაჭედილი დეპლოი სამ პრობლემად გამოიყურებოდა. სამივე pgbouncer-ის კონფიგში ჩაწერილი ერთი IP აღმოჩნდა.</description>
    </item>
    <item>
      <title>„დისკის შეცდომები“ OOM აღმოჩნდა: როგორ დაკარგეს Longhorn-ის ტომებმა ბექენდი</title>
      <link>https://stebas.com/ka/posts/longhorn-eio-was-node-oom/</link>
      <guid>https://stebas.com/ka/posts/longhorn-eio-was-node-oom/</guid>
      <pubDate>Fri, 31 Jul 2026 00:00:00 GMT</pubDate>
      <description>EIO, read-only ext4, დაზიანებული MySQL datadir და დალუქული Vault მომაკვდავ დისკს ჰგავდა. ჰოსტის dmesg-მა მთელი ნოდის OOM აჩვენა, რომელმაც პირველად Longhorn-ის instance-manager მოკლა.</description>
    </item>
    <item>
      <title>„Vault თავად ილუქება“ — არა, ის უბრალოდ არასოდეს იხსნება</title>
      <link>https://stebas.com/ka/posts/vault-shamir-reseals-on-restart/</link>
      <guid>https://stebas.com/ka/posts/vault-shamir-reseals-on-restart/</guid>
      <pubDate>Fri, 31 Jul 2026 00:00:00 GMT</pubDate>
      <description>Vault-ის პოდი დღეობით იდგა Ready 0/1-ზე, raft-ის კვორუმი კი ჩუმად ორ პირზე ინარჩუნებდა თავს. მას არავინ ლუქავდა: Shamir auto-unseal-ის გარეშე ყოველ რესტარტს დალუქულს ტოვებს.</description>
    </item>
    <item>
      <title>Longhorn-ის ტომი, რომელსაც გაზრდა არ სურდა: ცუდ ნოდაზე მიმაგრებული attachment ticket</title>
      <link>https://stebas.com/ka/posts/longhorn-online-expansion-stuck-on-bad-node/</link>
      <guid>https://stebas.com/ka/posts/longhorn-online-expansion-stuck-on-bad-node/</guid>
      <pubDate>Thu, 30 Jul 2026 00:00:00 GMT</pubDate>
      <description>PVC დაუსრულებლად იდგა Resizing-ში, Longhorn კი ყოველ ხუთ წამში იმეორებდა გაფართოებას ერთი შეცდომის გარეშე. მოძველებული attachment ticket ტომს ერთ არაჯანსაღ ნოდაზე აკავებდა.</description>
    </item>
    <item>
      <title>StatefulSet-ის უცვლელი ველის შეცვლა ერთი პოდის გადატვირთვის გარეშე</title>
      <link>https://stebas.com/ka/posts/resize-immutable-sts-field/</link>
      <guid>https://stebas.com/ka/posts/resize-immutable-sts-field/</guid>
      <pubDate>Thu, 30 Jul 2026 00:00:00 GMT</pubDate>
      <description>Git-ში 20 GiB, ცოცხალ StatefulSet-ში 6 GiB-იანი შაბლონები, Argo CD კი Synced-ს აჩვენებს. როგორ გადააწყო orphan წაშლამ და OnDelete-მა შაბლონი დაუნთაიმის გარეშე.</description>
    </item>
    <item>
      <title>ხუთი დღე 1/3-ზე მწვანე დაშბორდებით: როცა CRD-ის სტატუსი ცრუობს</title>
      <link>https://stebas.com/ka/posts/crd-status-lies-stalled-controller/</link>
      <guid>https://stebas.com/ka/posts/crd-status-lies-stalled-controller/</guid>
      <pubDate>Tue, 28 Jul 2026 00:00:00 GMT</pubDate>
      <description>MySQL InnoDB Cluster ხუთი დღე HA-ს გარეშე მუშაობდა, რესურსის სტატუსი, პოდების ფაზა და readiness gate კი ჯანმრთელობას აჩვენებდნენ. სამივე სიგნალი ერთი გაჭედილი ოპერატორიდან მოდიოდა.</description>
    </item>
    <item>
      <title>Helm წერს „another operation is in progress“, თუმცა არაფერი მიმდინარეობს</title>
      <link>https://stebas.com/ka/posts/helm-pending-upgrade-lock/</link>
      <guid>https://stebas.com/ka/posts/helm-pending-upgrade-lock/</guid>
      <pubDate>Mon, 13 Jul 2026 00:00:00 GMT</pubDate>
      <description>გაუქმებულმა CI ჯობმა ორი Helm რელიზი pending-upgrade-ში დატოვა და ყველა დეპლოი დაბლოკა. როგორ ვიპოვოთ lock, უსაფრთხოდ მოვხსნათ და მთელი namespace ერთბაშად შევამოწმოთ.</description>
    </item>
    <item>
      <title>როგორ ვუყურებ პლატფორმას</title>
      <link>https://stebas.com/ka/posts/hello/</link>
      <guid>https://stebas.com/ka/posts/hello/</guid>
      <pubDate>Thu, 16 Apr 2026 00:00:00 GMT</pubDate>
      <description>ინფრასტრუქტურა პროდუქტად, GitOps, CI/CD, DevSecOps — პროგნოზირებადი რელიზები და უსაფრთხოება პაიპლაინში.</description>
    </item>
  </channel>
</rss>
