Библиотека девопса | DevOps, SRE, Sysadmin
Все самое полезное для девопсера в одном канале. Наши курсы: https://clc.to/ZJ7Z1w По рекламе: @proglib_adv Для обратной связи: @proglibrary_feeedback_bot РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787
Ko'proq ko'rsatish📈 Telegram kanali Библиотека девопса | DevOps, SRE, Sysadmin analitikasi
Библиотека девопса | DevOps, SRE, Sysadmin (@devopsslib) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 10 389 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 11 426-o'rinni va Rossiya mintaqasida 61 246-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 10 389 obunachiga ega bo‘ldi.
29 Avgust, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni -2 ga, so‘nggi 24 soatda esa -1 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 10.44% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 4.23% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 1 085 marta ko‘riladi; birinchi sutkada odatda 439 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 1 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent devops'a, навигация, скрипт, docker, git kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Все самое полезное для девопсера в одном канале.
Наши курсы: https://clc.to/ZJ7Z1w
По рекламе: @proglib_adv
Для обратной связи: @proglibrary_feeedback_bot
РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 30 Avgust, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
kubelet выполняет аккуратное завершение: отправляет SIGTERM, ждёт до истечения terminationGracePeriodSeconds, останавливает контейнеры, размонтирует тома и сетевые пространства имён. Финальный шаг — удаление пода с ноды и из API.
Но если размонтирование не удаётся из-за ошибки "device or resource busy", процесс завершения зависает. API-объект остаётся в лимбо состояния Terminating навсегда.
Корень проблемы обычно один: рантайм контейнера оставил утечку — смонтированный том или процесс, который по-прежнему держит файловые дескрипторы.
Быстрая диагностика
Посмотреть есть ли на поде финализаторы:
kubectl get pod <POD> -o jsonpath='{.metadata.finalizers}'
Если они есть — не рубите их сплеча. Это обычно finalizer-ы хранилища (PVC, CSI), которые блокируют удаление до завершения очистки.
Нет финализаторов? Тогда ищем утечку монтирования на уровне хоста.
Подключитесь к ноде, где запускался под:
POD=pod-186o2
NS=default
UID=$(kubectl get pod $POD -n $NS -o jsonpath='{.metadata.uid}')
# На ноде смотрим, что смонтировано
grep -F "$UID" /proc/mounts || true
findmnt | grep "$UID" || true
Если видите записи типа /var/lib/kubelet/pods/<UID>/volumes/... — это ваш виновник.
Теперь узнаем, кто держит монтирование:
lsof +D /var/lib/kubelet/pods/$UID 2>/dev/null | head
Чистим руками
Для Docker:
docker ps --no-trunc | grep $POD
docker stop <containerID>
# Если совсем ничего не помогает (лаха!):
systemctl restart docker
Для containerd:
crictl ps | grep $POD
crictl stopp <containerID>
crictl rmp <containerID>
# Последняя линия защиты:
systemctl restart containerd
Если контейнер мёртв, но монтирование остаётся:
umount -l /var/lib/kubelet/pods/$UID/volumes/<driver>/<vol> || true
Теперь, когда освободили держание:
kubectl delete pod $POD -n $NS
Если всё ещё не уходит:
kubectl delete pod $POD -n $NS --grace-period=0 --force
Это API-уровневый молот. Безопасен для очистки зависшей записи, но используйте только после того, как разобрались с утечками на ноде. С особой осторожностью для StatefulSet.
Видите Terminating, который не уходит? Не спешите с --force. В девяти случаях из десяти kubelet вам что-то говорит: что-то остаётся смонтированным или используется.
🐸 Библиотека devops'a
#арсенал_инженераapiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"]Добавьте Pod Security Standards:
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
pod-security.kubernetes.io/enforce: restricted
Теперь в namespace нельзя запустить контейнер от root, с privileged, без securityContext.
Если нужна более гибкая политика — Kyverno или OPA Gatekeeper. Напишете правило один раз — оно будет работать для всех подов.
🐸 Библиотека devops'a
#арсенал_инженераapiVersion: v1
kind: Service
metadata:
name: backend
spec:
selector:
app: backend
ports:
- port: 80
targetPort: 8080
Разберитесь, как поды находят друг друга через DNS. Как ClusterIP балансирует запросы. Как работает Ingress.
Когда поймёте базу, добавьте Ingress-NGINX для внешнего трафика.
🐸 Библиотека devops'a
#арсенал_инженераmetadata:
labels:
owner: team-backend
purpose: experiment
expires: 2025-11-15
Теперь можно найти всё, что создала команда: kubectl get all -l owner=team-backend. Или всё, что просрочено.
Настройте сборку мусора. Kubernetes удалит зависимые объекты, если удалить владельца.
Используйте Kyverno для автоматического удаления ресурсов.
Делайте аудит раз в неделю: kubectl get all --all-namespaces. Ищите незнакомые имена, странные namespace. Удаляйте то, что не нужно.
🐸 Библиотека devops'a
#арсенал_инженера# Проверяем, что все нужные переменные заданы
required=(DB_URL OAUTH_CLIENT_ID OAUTH_SECRET REGION)
for v in "${required[@]}"; do
[ -n "${!v}" ] || { echo "::error::$v missing"; exit 78; }
done
Добавьте это в начало вашего скрипта CI. Код проходит по списку переменных и падает, если какая-то не установлена.
🐸 Библиотека devops'a
#арсенал_инженераbase/
deployment.yaml
service.yaml
overlays/
dev/
kustomization.yaml
prod/
kustomization.yaml
В overlay переопределяете replicas, resources, ConfigMap, Secrets. В dev можете вообще не использовать Secrets — подойдёт mock-конфиг. В prod — настоящий Secret из Sealed Secrets или внешнего Vault.
🐸 Библиотека devops'a
#арсенал_инженераnew_feature_flag: owner: web-platform created: 2025-09-08 expires: 2025-11-01После даты expires случается одно из двух: • CI выдаёт предупреждение на третий день просрочки • CI ломает сборку, если просрочка больше недели Разработчик не может игнорировать проблему, потому что его коммиты просто не пройдут. Проводите flag burn-down — 15-минутный митинг, где смотрите, какие флаги уже 100% включены в прод. 🐸 Библиотека devops'a #арсенал_инженера
containers:
- name: app
image: your-app:1.0
- name: fluent-bit
image: fluent/fluent-bit:latest
volumeMounts:
- name: varlog
mountPath: /var/log
Если нужна корреляция логов с метриками — добавьте OpenTelemetry. Если нужны трейсы — Jaeger. Но начните с простого: соберите логи в одном месте.
🐸 Библиотека devops'a
#арсенал_инженера