kr8s — это минималистичная, асинхронная и типизированная обёртка над Kubernetes API для Python.
Она предназначена для тех, кто хочет писать Kubernetes-автоматизацию или контроллеры (операторы) на чистом Python без необходимости использовать kubectl, YAML или громоздкие библиотеки.

Пример:

from kr8s import cluster, get

with cluster() as c:
    pods = get("pods", namespace="default")
    for pod in pods:
        print(pod.name, pod.status.phase)

Библиотека полностью асинхронна и поддерживает современные возможности Python, включая async for, тайпинги и кастомные ресурсы.


https://github.com/kr8s-org/kr8s

#devops #девопс

Подпишись 👉 @i_DevOps

🧯Как отключить историю Bash — навсегда и без следов

Иногда не хочется, чтобы команды сохранялись в истории (~/.bash_history). Особенно при работе с конфиденциальными данными.



🔒 Отключение истории в текущей сессии

Просто обнуляем переменные истории:

unset HISTFILE
export HISTSIZE=0
export HISTFILESIZE=0

💥 После этого Bash не будет сохранять историю вообще. Даже после выхода из сессии.



🧼 Стереть историю прямо сейчас

history -c    # очистить историю из памяти
> ~/.bash_history  # стереть файл истории

🔁 Отключить навсегда (для пользователя)

Добавь в ~/.bashrc или ~/.bash_profile:

export HISTFILE=
export HISTSIZE=0
export HISTFILESIZE=0

📌 После перезапуска оболочки история вестись не будет.



🧙 Дополнительно (опционально)

Чтобы Bash не пытался писать историю на выходе:

unset HISTFILE
trap "" EXIT

🛑 Будь осторожен! Без истории сложнее откатить действия. Но иногда это нужно: безопасность превыше всего 🔐

👉@bash_srv

Сбор данных мониторинга из Frontend JS приложений используя Grafana Faro

Здравствуйте. В данной статье будет выполнено рассмотрение и установка инструмента Grafana Faro для осуществления сбора данных мониторинга из Frontend приложений написанных на JavaScript. Также, перед непосредственным использованием Grafana Faro, выполним установку в кластере Kubernetes всех остальных необходимых компонентов Grafana стека.

https://habr.com/ru/articles/812065/

#devops #девопс

Подпишись 👉 @i_DevOps

Как эффективно масштабировать микросервисы с помощью контейнеров и Kubernetes на Go

Микросервисная архитектура — мощный подход к созданию масштабируемых и поддерживаемых приложений. Но по мере увеличения числа сервисов растёт и сложность управления ими. Использование контейнеров (например, Docker) в сочетании с Kubernetes позволяет упростить масштабирование, деплой и мониторинг микросервисов.

🔹 Почему Go?

Go (или Golang) отлично подходит для микросервисов:

- высокая производительность,
- быстрая компиляция,
- встроенная поддержка параллелизма,
- простота разработки и читаемость кода.

🔹 Контейнеризация микросервисов

Контейнеры позволяют упаковать приложение со всеми зависимостями в один изолированный образ. Для каждого микросервиса создается Docker-образ, который можно запускать на любой системе с Docker.

Пример Dockerfile для Go-сервиса:

FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o service

FROM alpine:latest
WORKDIR /root/
COPY --from=builder /app/service .
CMD ["./service"]

Этот подход позволяет минимизировать размер финального контейнера и ускорить запуск.

🔹 Оркестрация с помощью Kubernetes

Kubernetes управляет развертыванием и масштабированием контейнеров. Каждый микросервис разворачивается как Pod, а Deployment следит за его доступностью и масштабируемостью.

Пример Deployment для Go-сервиса:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: go-service
  template:
    metadata:
      labels:
        app: go-service
    spec:
      containers:
      - name: go-service
        image: your-repo/go-service:latest
        ports:
        - containerPort: 8080

Это создаёт три реплики сервиса, балансируя нагрузку между ними.

🔹 Сервис-дискавери и балансировка

Kubernetes автоматически предоставляет DNS и IP для взаимодействия между сервисами. Компонент Service в Kubernetes позволяет направлять трафик к нужным Pod'ам и осуществлять балансировку.

🔹 Мониторинг и масштабирование

Интеграция с Prometheus и Grafana обеспечивает мониторинг метрик. Kubernetes также позволяет настраивать автоматическое масштабирование (HPA) в зависимости от загрузки CPU или других метрик.

Пример HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: go-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: go-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

https://blog.stackademic.com/how-to-effectively-scale-microservices-using-containers-and-kubernetes-on-go-1fb05fccb089


#devops #девопс

Подпишись 👉@i_DevOps

🧪 K8E — это форк проекта K3s, предназначенный для локального тестирования.
Он не требует root-доступа и не использует systemd.
Также вы можете легко собрать и запустить его без сетевого подключения (air-gap режим).

Основные особенности:
- Без root-доступа
- Без systemd
- Один бинарник
- Простой запуск кластера: k8e server &
- Не требует внешней сети
- Поддерживает полностью автономную сборку

Если вы когда-либо хотели поднять Kubernetes-кластер за пару секунд и без привилегий — этот инструмент идеально подойдёт для тестов и локальной разработки.

https://github.com/xiaods/k8e

#devops #девопс

Подпишись 👉@i_DevOps

Как вам такой системник ?

Подписывайтесь на канал 👉@tipsysdmin

Собрал основные концепции Docker в одну диаграмму

#devops #девопс

Подпишись 👉@i_DevOps

Kubernetes Crash Course for Absolute Beginners

0:00 - Intro and Course Overview
1:44 - What is Kubernetes
4:33 - Kubernetes Architecture
9:29 - Node and Pod
8:58 - Main K8s Components
09:29 - Node & Pod
12:19 - Service & Ingress
14:31 - ConfigMap & Secret
17:52 - Volume
19:46 - Deployment & StatefulSet
26:28 - Kubernetes Configuration
32:39 - Minikube and Kubectl - Setup K8s cluster locally
41:17 - Complete Demo Project: Deploy WebApp with MongoDB
1:05:40 - Interacting with Kubernetes Cluster
1:11:03 - Congrats! You made it to the end 🎉

источник

#devops #девопс

Подпишись 👉@i_DevOps

Zed — это высокопроизводительный текстовый редактор, ориентированный на разработчиков. Он написан на Rust и использует пользовательский движок рендеринга на базе GPU для достижения минимальных задержек. Архитектура Zed основана на многопоточности и асинхронности, что позволяет редактору эффективно использовать ресурсы современных многоядерных систем.

Редактор также разрабатывается с упором на совместную работу в реальном времени: Zed предлагает встроенные функции для коллаборации между разработчиками — от редактирования кода до видеозвонков. Это делает его особенно удобным для удалённых команд.

Среди особенностей:
- Мгновенный отклик и плавная анимация благодаря GPU-рендерингу
- Полноценная поддержка нескольких курсоров и мощное автодополнение
- Интеграция с языковыми серверами (LSP)
- Глубокая коллаборативность: совместное редактирование, общие терминалы, голос и видео


https://github.com/zed-industries/zed

#devops #девопс

Подпишись 👉@i_DevOps

Путь в DevOps: полное руководство для новичков с НУЛЯ - 2025

00:00 - Вступление
00:14 - Всевозможные компетенции DevOps Инженера
00:44 - Кому проще стать DevOps Инженером
02:29 - Что учить по минимуму и в каком порядке
10:27 - 1. Основы Networking TCP/IP
11:46 - 2. Администрирование Windows
12:38 - 3. Основы Linux
13:28 - 4. Ansible
13:56 - 5. Git
14:26 - 6. GitHub
14:52 - 7. CI/CD: GitHub Actions, GitLab CI/CD
15:29 - 8. Docker + DockerHub
16:16 - 9. Kubernetes + Helm + ArgoCD
17:04 - 10. AWS: Amazon Web Services
19:12 - 10. GCP: Google Cloud Platform
20:27 - 10. Azure: Microsoft Azure
21:38 - 11. Terraform + Terragrunt
22:42 - 12. Python
23:09 - Как стать профессиональным DevOps Ннженером
24:37 - Девопс это хорошее будущее вашей карьеры

источник

#devops #девопс

Подпишись 👉@i_DevOps

#devops #девопс

Подпишись 👉@i_DevOps

Каким образом мы можем управлять вычислительными ресурсами в k8s?

Для эффективного управления ресурсами в кластере k8s используются resources requests / limits. Они могут быть настроены для CPU, памяти и, в последних версиях k8s, для GPU.

Requests используются для определения типичного потребления ресурсов нашим приложением. На основе этих данных Kubernetes scheduler выбирает ноды для запуска PODов (сумма всех request'ов контейнеров во всех PODах не должна превышать доступные ресурсы на ноде).

Limits служат как механизм предотвращения, ограничивая потребление ресурсов контейнером в PODе. При превышении лимита процессорного времени применяется thermal throttling, а при превышении лимита памяти — механизм OOM.

Модель, при которой requests меньше limits, называется burstable QoS, а когда requests равны limits — guaranteed QoS.

Кроме того, можно установить квоты ресурсов на namespace (CPU, память, количество запущенных PODов, размер диска persistent volume) и указать требования к resources requests на PODах в namespace с помощью limit ranges.

Для управления ресурсами приложений также можно использовать автоскейлеры. В k8s доступны HPA (horizontal pod autoscaler), который регулирует количество PODов в зависимости от потребления CPU и/или памяти, и VPA (vertical pod autoscaler), который управляет resources requests / limits.

Существуют также реализации автоскейлеров, которые могут использовать внешние метрики (например, длину очереди), такие как carpenter или KEDA. В облачном окружении можно использовать cluster autoscaler для добавления или удаления нод в зависимости от общей загрузки кластера.

#devops #девопс

Подпишись 👉@i_DevOps

13 законов разработки ПО

Некоторые из них хорошо известны, другие — достаточно нишевые. Но все они очень полезны разработчикам и менеджерам. Любопытно, какие из них вам известны:

Закон Паркинсона.
Закон Хофштадтера.
Закон Брукса.
Закон Конвея (и обратный закон Конвея).
Закон Каннингема.
Закон Старджона.
Закон Завински.
Закон Хайрама.
Закон Прайса.
Эффект Рингельмана.
Закон Гудхарта.
Закон Гилба.
Закон Мёрфи.

https://habr.com/ru/companies/ruvds/articles/898254/

#devops #девопс

Подпишись 👉@i_DevOps