[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fb3K_DEiXvriS2sacQInJyGPNIFvotG45YTLSF-OG3D8":3},{"data":4,"related":91},{"id":5,"title":6,"slug":7,"excerpt":8,"cover":9,"category":11,"author":14,"track":20,"level":23,"reading_minutes":26,"is_featured":27,"published_at":28,"updated_at":28,"body":29,"toc":30,"tags":63,"faqs":76,"related_services":86,"comments_enabled":89,"meta_title":19,"meta_description":90,"canonical_url":19,"noindex":27,"is_live":89},12,"خطای fsnotify watcher در Kubernetes؛ سقف inotify نود","kubernetes-fsnotify-watcher-inotify-limit","اگر پادهای Grafana، Prometheus یا هر اپلیکیشنی که از inotify استفاده می‌کند با خطای «failed to create fsnotify watcher: too many open files» کرش می‌کنند، مقصر سقف پیش‌فرض هسته لینوکس روی نود است.",{"url":10,"alt":6},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F4781a89b-ab2c-4250-9677-521b30f6f643.webp",{"name":12,"slug":13},"Kubernetes و کانتینر","kubernetes",{"name":15,"slug":16,"role":17,"bio":18,"linkedin_url":19,"avatar_url":19},"تحریریه کلودیکپ","cloudicap-editorial","تیم محتوای کلودیکپ","تیم فنی و محتوای کلودیکپ؛ مهندسانی که هر روز با DevOps، Kubernetes و زیرساخت ابری کار می‌کنند و تجربه‌هایشان را اینجا می‌نویسند.",null,{"value":21,"label":22},"engineers","مهندسان",{"value":24,"label":25},"intermediate","متوسط",7,false,"2026-10-13T09:37:29+00:00","\u003Ch2 id=\"شرح-مسئله-کرش-پاد-با-پیام-failed-to-create-fsnotify-watcher\">شرح مسئله: کرش پاد با پیام failed to create fsnotify watcher\u003C\u002Fh2>\n\u003Cp>یکی از سناریوهای پرتکرار در کلاسترهایی که اپ‌های file-watcher اجرا می‌کنند، این است که پادها به‌شکل ناگهانی به CrashLoopBackOff می‌افتند یا رول‌آوت یک Deployment وسط راه گیر می‌کند. لاگ کانتینر معمولاً چیزی شبیه این نشان می‌دهد:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">level=error msg=\"failed to create fsnotify watcher: too many open files\" logger=ngalert.sender.router\nlevel=error msg=\"failed to start alertmanager: failed to create fsnotify watcher: too many open files\"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>نشانه‌های همراه که معمولاً کنارش دیده می‌شوند:\u003C\u002Fp>\n\u003Cul>\n  \u003Cli>پاد بعد از چند ثانیه کارکرد ری‌استارت می‌شود و \u003Ccode>kubectl describe pod\u003C\u002Fcode> دلیل \u003Ccode>Error\u003C\u002Fcode> یا \u003Ccode>OOMKilled\u003C\u002Fcode> را نشان می‌دهد، در حالی که مصرف حافظه پایین است.\u003C\u002Fli>\n  \u003Cli>خطای مشابه روی سرویس‌های مختلف همان نود تکرار می‌شود؛ مثلاً هم‌زمان Grafana و Node Exporter و یک اپلیکیشن Node.js.\u003C\u002Fli>\n  \u003Cli>بعد از ری‌استارت کلاستر یا اضافه‌کردن چند workload جدید، مشکل تازه ظاهر شده است.\u003C\u002Fli>\n  \u003Cli>اگر تعداد پادها را روی همان نود کمتر کنید، مشکل خودبه‌خود محو می‌شود — که گمراه‌کننده است و مهندس را به سمت مشکل منابع (CPU\u002FMemory) می‌فرستد.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>یکی از سردرگمی‌های رایج این است که پیام «too many open files» شبیه خطای \u003Ccode>ulimit -n\u003C\u002Fcode> است، در حالی که اینجا موضوع کاملاً متفاوت است: محدودیت \u003Cem>inotify\u003C\u002Fem> هسته لینوکس، نه file descriptor هر پروسه.\u003C\u002Fp>\n\n\u003Ch2 id=\"علت-ریشه‌ای-سقف-inotify-هسته-نه-منابع-پاد\">علت ریشه‌ای: سقف inotify هسته، نه منابع پاد\u003C\u002Fh2>\n\u003Cp>لینوکس برای پشتیبانی از watch کردن فایل‌ها و دایرکتوری‌ها، سه محدودیت per-user دارد که از طریق kernel در اختیار همه پروسه‌ها قرار می‌گیرد:\u003C\u002Fp>\n\u003Ctable>\n  \u003Cthead>\u003Ctr>\u003Cth>پارامتر\u003C\u002Fth>\u003Cth>مقدار پیش‌فرض معمول\u003C\u002Fth>\u003Cth>کاربرد\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\u003Ctd>\u003Ccode>fs.inotify.max_user_instances\u003C\u002Fcode>\u003C\u002Ftd>\u003Ctd>128\u003C\u002Ftd>\u003Ctd>تعداد نمونه‌های inotify که یک کاربر می‌تواند بسازد\u003C\u002Ftd>\u003C\u002Ftr>\n    \u003Ctr>\u003Ctd>\u003Ccode>fs.inotify.max_user_watches\u003C\u002Fcode>\u003C\u002Ftd>\u003Ctd>8192\u003C\u002Ftd>\u003Ctd>تعداد کل watch های فعال یک کاربر\u003C\u002Ftd>\u003C\u002Ftr>\n    \u003Ctr>\u003Ctd>\u003Ccode>fs.inotify.max_queued_events\u003C\u002Fcode>\u003C\u002Ftd>\u003Ctd>16384\u003C\u002Ftd>\u003Ctd>صف رویدادهای در انتظار پردازش\u003C\u002Ftd>\u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>کتابخانه‌هایی مثل \u003Ccode>fsnotify\u003C\u002Fcode> در Go یا \u003Ccode>chokidar\u003C\u002Fcode> در Node.js، برای هر watcher یک \u003Cem>inotify instance\u003C\u002Fem> جدا باز می‌کنند. Grafana وقتی Unified Alerting را روشن می‌کند، Prometheus برای hot-reload کردن فایل کانفیگ، Java WatchService و بسیاری از سرویس‌های دیگر هم همین رفتار را دارند. همه این‌ها روی نود به یک user (معمولاً root، چون کانتینرها به‌طور پیش‌فرض به همان user namespace نود نگاه می‌کنند) حساب می‌شوند.\u003C\u002Fp>\n\u003Cp>یعنی وقتی روی یک نود مثلاً ۲۰ پاد file-watcher دارید و هر کدام چند instance می‌سازد، خیلی سریع به سقف ۱۲۸ می‌خورید و پروسه بعدی که سعی می‌کند inotify instance بسازد، با خطای \u003Ccode>EMFILE\u003C\u002Fcode> و پیام \u003Ccode>too many open files\u003C\u002Fcode> رد می‌شود. این سقف توسط \u003Ca href=\"\u002Fservices\u002Fkubernetes\">Kubernetes\u003C\u002Fa> مدیریت نمی‌شود و از ایمیج نود یا توزیع لینوکس ارث می‌رسد.\u003C\u002Fp>\n\n\u003Ch2 id=\"راه‌حل-گام‌به‌گام\">راه‌حل گام‌به‌گام\u003C\u002Fh2>\n\n\u003Ch3 id=\"گام-۱-تأیید-مقدار-فعلی-روی-نود\">گام ۱: تأیید مقدار فعلی روی نود\u003C\u002Fh3>\n\u003Cp>از روی خود نود یا با یک Pod مخصوص تروبل‌شوتینگ، مقادیر را بخوانید. این مقادیر kernel-global هستند و از داخل کانتینر هم دیده می‌شوند:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">sudo sysctl fs.inotify.max_user_instances fs.inotify.max_user_watches fs.inotify.max_queued_events\n# خروجی نمونه\n# fs.inotify.max_user_instances = 128\n# fs.inotify.max_user_watches = 8192\n# fs.inotify.max_queued_events = 16384\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>برای اطمینان از اینکه مشکل واقعاً همین است، تعداد instance های inotify فعال روی نود را بشمارید. اگر نزدیک سقف یا بالاتر از آن است، تشخیص تأیید می‌شود:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">sudo find \u002Fproc\u002F*\u002Ffd -lname anon_inode:inotify 2>\u002Fdev\u002Fnull | wc -l\n# خروجی نمونه: 124\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Ch3 id=\"گام-۲-افزایش-موقت-برای-صحت‌سنجی-سریع\">گام ۲: افزایش موقت برای صحت‌سنجی سریع\u003C\u002Fh3>\n\u003Cp>اولین کار، بالا بردن مقدار در حافظه است تا مطمئن شوید مشکل حل می‌شود. این تغییر با ری‌استارت نود از دست می‌رود:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">sudo sysctl -w fs.inotify.max_user_instances=8192\nsudo sysctl -w fs.inotify.max_user_watches=524288\nsudo sysctl -w fs.inotify.max_queued_events=32768\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>پادهای مشکل‌دار را دوباره راه‌اندازی کنید (با \u003Ccode>kubectl rollout restart\u003C\u002Fcode>) و لاگ‌ها را ببینید. اگر خطا رفت، گام بعدی را برای پایداری انجام دهید.\u003C\u002Fp>\n\n\u003Ch3 id=\"گام-۳-پایداری-روی-نود\">گام ۳: پایداری روی نود\u003C\u002Fh3>\n\u003Cp>یک فایل جداگانه در \u003Ccode>\u002Fetc\u002Fsysctl.d\u003C\u002Fcode> بسازید تا با هر بوت اعمال شود. مقدار پیشنهادی برای کلاسترهای متوسط و بزرگ:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-ini\"># \u002Fetc\u002Fsysctl.d\u002F99-inotify.conf\nfs.inotify.max_user_instances = 8192\nfs.inotify.max_user_watches = 524288\nfs.inotify.max_queued_events = 32768\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>سپس:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">sudo sysctl --system\nsudo sysctl fs.inotify.max_user_instances\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر نودها را با cloud-init، Ansible، Packer یا MachineConfig (در OpenShift) پروویژن می‌کنید، همین فایل باید بخشی از تصویر پایه نود باشد. برای EKS با Karpenter یا managed node group، از user-data و launch template استفاده کنید.\u003C\u002Fp>\n\n\u003Ch3 id=\"گام-۴-اعمال-cluster-wide-با-daemonset-fallback\">گام ۴: اعمال cluster-wide با DaemonSet (fallback)\u003C\u002Fh3>\n\u003Cp>وقتی به دلایلی نمی‌توانید ایمیج یا user-data نود را تغییر دهید (مثلاً کلاستر under حمایت تیم زیرساخت دیگری است)، این DaemonSet را با علم به ماهیت privileged آن به‌کار ببرید. روی هر نود، sysctl هاست را با \u003Ccode>nsenter\u003C\u002Fcode> از PID 1 تغییر می‌دهد:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-yaml\">apiVersion: apps\u002Fv1\nkind: DaemonSet\nmetadata:\n  name: inotify-tuner\n  namespace: kube-system\n  labels:\n    app.kubernetes.io\u002Fname: inotify-tuner\nspec:\n  selector:\n    matchLabels:\n      app.kubernetes.io\u002Fname: inotify-tuner\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io\u002Fname: inotify-tuner\n    spec:\n      hostPID: true\n      tolerations:\n        - operator: Exists\n      initContainers:\n        - name: sysctl\n          image: alpine:3.20\n          securityContext:\n            privileged: true\n          command:\n            - nsenter\n            - --target=1\n            - --mount\n            - --uts\n            - --ipc\n            - --net\n            - --pid\n            - --\n            - sysctl\n            - -w\n            - fs.inotify.max_user_instances=8192\n            - fs.inotify.max_user_watches=524288\n            - fs.inotify.max_queued_events=32768\n      containers:\n        - name: pause\n          image: registry.k8s.io\u002Fpause:3.9\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>نکته مهم: این تغییر هم موقتی است و بعد از ری‌استارت نود از بین می‌رود؛ چون کارش \u003Ccode>sysctl -w\u003C\u002Fcode> است نه نوشتن در \u003Ccode>\u002Fetc\u002Fsysctl.d\u003C\u002Fcode>. برای پایداری واقعی، همان گام ۳ روی ایمیج نود ضروری است و این DaemonSet را فقط به‌عنوان پنچر عملیاتی در نظر بگیرید که بعد از هر بوت مجدد باید دوباره اجرا شود (که در واقعیت خودش می‌تواند منبع دردسر باشد، پس ترجیح دهید حل را در لایه پروویژنینگ نود انجام دهید).\u003C\u002Fp>\n\n\u003Ch3 id=\"گام-۵-اجرای-مجدد-workload-مشکل‌دار\">گام ۵: اجرای مجدد workload مشکل‌دار\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-bash\">kubectl rollout restart deployment\u002Fgrafana -n monitoring\nkubectl rollout status deployment\u002Fgrafana -n monitoring\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Ch2 id=\"بررسی-اینکه-مشکل-واقعا-حل-شده-است\">بررسی اینکه مشکل واقعاً حل شده است\u003C\u002Fh2>\n\u003Cp>سه چک سریع، تصویر کامل می‌دهد:\u003C\u002Fp>\n\u003Col>\n  \u003Cli>مقدار جدید باید از داخل خود پاد هم دیده شود، چون این سقف node-global است:\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cpre>\u003Ccode class=\"language-bash\">kubectl exec -it deploy\u002Fgrafana -n monitoring -- cat \u002Fproc\u002Fsys\u002Ffs\u002Finotify\u002Fmax_user_instances\n# خروجی باید 8192 باشد، نه 128\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Col start=\"2\">\n  \u003Cli>در لاگ پاد، پیام \u003Ccode>fsnotify watcher\u003C\u002Fcode> نباید دیگر ظاهر شود:\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cpre>\u003Ccode class=\"language-bash\">kubectl logs deploy\u002Fgrafana -n monitoring --since=30m | grep -i fsnotify || echo \"OK: no fsnotify errors\"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Col start=\"3\">\n  \u003Cli>شمارش تعداد instance های فعال روی نود باید الان به‌طور معناداری پایین‌تر از سقف جدید باشد:\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cpre>\u003Ccode class=\"language-bash\">sudo find \u002Fproc\u002F*\u002Ffd -lname anon_inode:inotify 2>\u002Fdev\u002Fnull | wc -l\n# انتظار: عددی در محدوده چند صد، در حالی که سقف 8192 است\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر خطا برگشت ولی سقف بالا رفته، احتمالاً مشکل از یک اپ با نشتی inotify است؛ در این حالت شمارش per-process را بررسی کنید و ببینید کدام پاد مداوم instance می‌سازد و رها نمی‌کند.\u003C\u002Fp>\n\n\u003Ch2 id=\"پیشگیری-و-بهترین-روش‌ها\">پیشگیری و بهترین روش‌ها\u003C\u002Fh2>\n\u003Cul>\n  \u003Cli>\u003Cstrong>در ایمیج پایه نود بگذارید، نه در runtime.\u003C\u002Fstrong> فایل \u003Ccode>\u002Fetc\u002Fsysctl.d\u002F99-inotify.conf\u003C\u002Fcode> را در cloud-init، Packer، AMI پایه یا MachineConfig بگنجانید تا هر نود جدید با تنظیم درست بالا بیاید.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>مقدار را بر اساس تعداد پاد پیش‌بینی کنید.\u003C\u002Fstrong> برای هر پاد file-watcher چیزی بین ۵ تا ۲۰ instance در نظر بگیرید و سقف را با ضریب اطمینان بگذارید. برای اکثر کلاسترها \u003Ccode>8192\u003C\u002Fcode> برای instance و \u003Ccode>524288\u003C\u002Fcode> برای watch کافی است.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>مصرف را مانیتور کنید.\u003C\u002Fstrong> با Node Exporter و یک textfile collector، تعداد instance های فعال را به معیار تبدیل کنید و آلارم روی نسبت به سقف (مثلاً ۷۰٪) بگذارید. آلارم روی «کرش پاد» دیر است؛ باید قبلش متوجه شوید.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>خود اپ را بهینه کنید.\u003C\u002Fstrong> اگر Grafana یا هر سرویس دیگری Unified Alerting، hot reload یا file watching ندارد که واقعاً به آن نیاز دارید، غیرفعالش کنید. Prometheus را با \u003Ccode>--web.enable-lifecycle\u003C\u002Fcode> و بدون watch روی فایل‌های mount شده سنگین بالا نیاورید.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>محدودیت را در سمت بار کاری هم در نظر بگیرید.\u003C\u002Fstrong> قید \u003Ccode>securityContext.runAsUser\u003C\u002Fcode> با UID متفاوت برای اپ‌های پرحجم، سهمیه‌ی inotify را از root جدا می‌کند و از برخورد منابع در یک نود جلوگیری می‌کند.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>مستند کنید.\u003C\u002Fstrong> این تنظیم را به‌عنوان بخشی از «baseline نود» در runbook تیم نگه دارید تا هر کسی که کلاستر جدید می‌سازد آن را لحاظ کند؛ در غیر این‌صورت مشکل چند ماه بعد در محیط production دوباره سر باز می‌کند.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>خطای fsnotify watcher در نگاه اول شبیه یک باگ اپلیکیشنی به‌نظر می‌رسد، اما در واقع یک تنظیم فراموش‌شده در لایه نود است. با بالا بردن سقف inotify در پروویژن نود و مانیتور کردن مصرف، این دسته از کرش‌ها را برای همیشه از سبد تیکت‌های عملیاتی حذف می‌کنید.\u003C\u002Fp>",[31,35,38,41,45,48,51,54,57,60],{"id":32,"text":33,"level":34},"شرح-مسئله-کرش-پاد-با-پیام-failed-to-create-fsnotify-watcher","شرح مسئله: کرش پاد با پیام failed to create fsnotify watcher",2,{"id":36,"text":37,"level":34},"علت-ریشه‌ای-سقف-inotify-هسته-نه-منابع-پاد","علت ریشه‌ای: سقف inotify هسته، نه منابع پاد",{"id":39,"text":40,"level":34},"راه‌حل-گام‌به‌گام","راه‌حل گام‌به‌گام",{"id":42,"text":43,"level":44},"گام-۱-تأیید-مقدار-فعلی-روی-نود","گام ۱: تأیید مقدار فعلی روی نود",3,{"id":46,"text":47,"level":44},"گام-۲-افزایش-موقت-برای-صحت‌سنجی-سریع","گام ۲: افزایش موقت برای صحت‌سنجی سریع",{"id":49,"text":50,"level":44},"گام-۳-پایداری-روی-نود","گام ۳: پایداری روی نود",{"id":52,"text":53,"level":44},"گام-۴-اعمال-cluster-wide-با-daemonset-fallback","گام ۴: اعمال cluster-wide با DaemonSet (fallback)",{"id":55,"text":56,"level":44},"گام-۵-اجرای-مجدد-workload-مشکل‌دار","گام ۵: اجرای مجدد workload مشکل‌دار",{"id":58,"text":59,"level":34},"بررسی-اینکه-مشکل-واقعا-حل-شده-است","بررسی اینکه مشکل واقعاً حل شده است",{"id":61,"text":62,"level":34},"پیشگیری-و-بهترین-روش‌ها","پیشگیری و بهترین روش‌ها",[64,65,68,71,74],{"name":13,"slug":13},{"name":66,"slug":67},"Grafana","grafana",{"name":69,"slug":70},"Linux","linux",{"name":72,"slug":73},"Troubleshooting","troubleshooting",{"name":75,"slug":75},"inotify",[77,80,83],{"question":78,"answer":79},"چرا خطای fsnotify watcher به‌نظر مربوط به منابع پاد است ولی نیست؟","متن «too many open files» معمولاً مهندس را به سمت ulimit و file descriptor هر پروسه می‌برد، اما این خطا در واقع از سقف inotify هسته لینوکس می‌آید که per-user (معمولاً root) است و بین همه پادهای روی همان نود مشترک است. بالا بردن limit پاد یا CPU\u002FMemory بی‌فایده است.",{"question":81,"answer":82},"آیا افزایش سقف inotify روی نود به حافظه قابل توجهی نیاز دارد؟","هر watch در هسته چیزی در حدود یک کیلوبایت اشغال می‌کند؛ پس ۵۲۴۲۸۸ watch حدود چند صد مگابایت سقف مصرف دارد. چون این سقف است نه تخصیص، حافظه فقط در صورت استفاده واقعی مصرف می‌شود. برای اکثر کلاسترها بین ۱۲۸ تا ۵۱۲ هزار watch کاملاً امن است.",{"question":84,"answer":85},"چرا DaemonSet تغییر sysctl پس از ری‌استارت نود کار نمی‌کند؟","چون آن DaemonSet با sysctl -w مقدار را فقط در حافظه هسته اعمال می‌کند و در فایل پیکربندی نمی‌نویسد. برای پایداری باید فایل \u002Fetc\u002Fsysctl.d روی ایمیج نود یا در cloud-init قرار بگیرد تا با هر بوت اعمال شود.",[87,13,88],"devops-consulting","cloud-infrastructure",true,"رفع خطای fsnotify watcher در Kubernetes با افزایش سقف inotify نود به‌صورت موقت و پایدار، و اعمال cluster-wide روی همه نودها.",[92,104,117],{"id":93,"title":94,"slug":95,"excerpt":96,"cover":97,"category":99,"author":100,"track":101,"level":102,"reading_minutes":26,"is_featured":27,"published_at":103,"updated_at":103},11,"تأخیر ۵ ثانیه‌ای DNS در Kubernetes؛ پای ndots:5 در میان است","kubernetes-dns-ndots5-latency","هرچند وقت یک‌بار یک درخواست خروجی دقیقاً ۵ ثانیه طول می‌کشد و بعد موفق می‌شود؟ ریشه معمولاً گزینه ndots:5 در resolv.conf پادها و لیست search است. این مقاله علت، تشخیص و راه‌حل کامل را بررسی می‌کند.",{"url":98,"alt":94},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F79a6c679-300c-4c45-b692-9edb968f1d49.webp",{"name":12,"slug":13},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},"2026-10-12T09:53:03+00:00",{"id":105,"title":106,"slug":107,"excerpt":108,"cover":109,"category":111,"author":112,"track":113,"level":114,"reading_minutes":115,"is_featured":27,"published_at":116,"updated_at":116},9,"پاد Kubernetes در وضعیت Terminating گیر کرده؛ آزادسازی امن","kubernetes-pod-stuck-terminating-finalizer","پاد در حالت Terminating گیر کرده و با kubectl delete پاک نمی‌شود؟ این مقاله علت واقعی (finalizer باقی‌مانده، نود NotReady، ولوم گیرکرده) و راه‌حل گام‌به‌گام امن را نشان می‌دهد.",{"url":110,"alt":106},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F8e6369a3-ad85-4e7e-8588-183bbd5a31f9.webp",{"name":12,"slug":13},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},6,"2026-10-10T09:34:08+00:00",{"id":44,"title":118,"slug":119,"excerpt":120,"cover":121,"category":123,"author":125,"track":126,"level":127,"reading_minutes":26,"is_featured":27,"published_at":128,"updated_at":128},"قطع شدن WebSocket در HAProxy هر ۵۰ ثانیه؛ علت و راه‌حل","haproxy-websocket-timeout-50s","اگر WebSocket یا SSE پشت HAProxy هر ۵۰ ثانیه قطع می‌شود، مقصر تایماوت‌های پیش‌فرض فایل نمونه است. در این مقاله علت ریشه‌ای و پیکربندی درست timeout tunnel را بررسی می‌کنیم.",{"url":122,"alt":118},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F26b583b4-d805-45d6-a265-a94d73b5a21d.webp",{"name":124,"slug":70},"Linux و مدیریت سرور",{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},"2026-10-07T07:57:29+00:00"]