Библиотека девопса | DevOps, SRE, Sysadmin
Все самое полезное для девопсера в одном канале. Наши курсы: https://clc.to/ZJ7Z1w По рекламе: @proglib_adv Для обратной связи: @proglibrary_feeedback_bot РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787
Show more📈 Analytical overview of Telegram channel Библиотека девопса | DevOps, SRE, Sysadmin
Channel Библиотека девопса | DevOps, SRE, Sysadmin (@devopsslib) in the Russian language segment is an active participant. Currently, the community unites 10 389 subscribers, ranking 11 426 in the Technologies & Applications category and 61 246 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 10 389 subscribers.
According to the latest data from 29 August, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -2 over the last 30 days and by -1 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 10.44%. Within the first 24 hours after publication, content typically collects 4.23% reactions from the total number of subscribers.
- Post reach: On average, each post receives 1 085 views. Within the first day, a publication typically gains 439 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 1.
- Thematic interests: Content is focused on key topics such as devops'a, навигация, скрипт, docker, git.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Все самое полезное для девопсера в одном канале.
Наши курсы: https://clc.to/ZJ7Z1w
По рекламе: @proglib_adv
Для обратной связи: @proglibrary_feeedback_bot
РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787”
Thanks to the high frequency of updates (latest data received on 30 August, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
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
#арсенал_инженера