📌 Kubernetes 101: назначение Pod'ов на узлы

В статье подробно рассматриваются механизмы назначения Pod'ов на узлы в Kubernetes. Автор объясняет такие инструменты, как nodeSelector, nodeAffinity и taints/tolerations, которые позволяют контролировать, где именно будут запускаться ваши Pod'ы.

🔧 Основные моменты:
- nodeSelector — простой способ указать, на каком узле должен работать Pod.
- Node Affinity — более гибкий способ задания условий, включая hard и soft требования.
- Taints и Tolerations — эффективный способ предотвращать запуск Pod'ов на неподходящих узлах, если те не "терпят" заданные taints.

Эти инструменты помогают оптимизировать использование ресурсов кластера и избегать перегрузки узлов.

https://hwchiu.medium.com/kubernetes-101-assigning-pod-to-nodes-e52eebb4bc38

📲 Мы в MAX

#devops #девопс

👉 @devops_star

Какая роль у контроллера DaemonSet?

Контроллер DaemonSet в Kubernetes играет важную роль в обеспечении того, чтобы определённый под (Pod) запускался на каждом узле (Node) кластера (или на определённом подмножестве узлов, если заданы ограничения). Основные задачи и функции контроллера DaemonSet:

1. Запуск подов на каждом узле
- DaemonSet гарантирует, что на каждом узле кластера будет запущен экземпляр указанного пода.
- Это полезно для задач, которые должны выполняться на каждом узле, например:
- Сбор логов (например, Fluentd, Logstash).
- Мониторинг (например, Prometheus Node Exporter).
- Сетевые плагины (например, Calico, Weave).
- Хранение данных (например, распределённые хранилища).

2. Автоматическое добавление подов при добавлении новых узлов
- Когда в кластер добавляется новый узел, DaemonSet автоматически создаёт на нём под.
- Это обеспечивает согласованность и автоматизацию развёртывания.

3. Удаление подов при удалении узлов
- Если узел удаляется из кластера, DaemonSet автоматически удаляет под, связанный с этим узлом.

4. Поддержка селекторов и толерантностей
- DaemonSet позволяет использовать селекторы для выбора узлов, на которых будут запускаться поды.
- Также можно использовать толерантности (tolerations), чтобы разрешить запуск подов на узлах с определёнными метками (например, на узлах с taint node-role.kubernetes.io/master).

5. Обновление и управление подами
- DaemonSet поддерживает стратегии обновления (например, RollingUpdate или OnDelete), что позволяет обновлять поды на узлах с минимальным простоем.
- Контроллер следит за состоянием подов и обеспечивает их корректную работу.


Примеры использования DaemonSet:
- Сетевые плагины: Запуск сетевых агентов на каждом узле для обеспечения сетевой связности.
- Мониторинг: Запуск агентов сбора метрик (например, Prometheus Node Exporter) на каждом узле.
- Логирование: Запуск агентов сбора логов (например, Fluentd) на каждом узле.
- Хранение данных: Запуск компонентов распределённых хранилищ (например, Ceph, GlusterFS).

Отличие DaemonSet от других контроллеров:
- Deployment: Запускает определённое количество реплик подов, которые могут быть распределены по любым узлам.
- StatefulSet: Управляет подами с устойчивыми идентификаторами и хранилищем.
- DaemonSet: Запускает по одному поду на каждом узле (или на подмножестве узлов).


Таким образом, роль контроллера DaemonSet заключается в обеспечении запуска и поддержания определённого пода на каждом узле кластера, что делает его идеальным инструментом для задач, которые должны выполняться на всех узлах.

📲 Мы в MAX

#devops #девопс

👉 @devops_star

Шпаргалка по Git для разработчиков и инженеров DevOps

📲 Мы в MAX

#devops #девопс

👉 @devops_star

Освоение командной строки curl с Дэниелом Стенбергом

0:00 Mastering the curl command line
0:16 Daniel Stenberg
0:36 curl support by wolfSSL
0:56 setup
02:20 questions
02:52 agenda
05:25 The project
05:42 take-off
07:42 name
09:17 main products
10:48 open source
.................
3:15:50 HTTP/2
3:17:20 HTTP/3
3:18:44 HTTP/3 racing
3:20:57 HTTP alt-svc
3:22:50 HTTP HSTS
3:24:39 FTP
3:25:42 FTP(S) is not SFTP
3:26:17 FTP uses two connections
3:28:43 FTP authentication
3:29:06 FTP directory listing
3:30:24 FTP upload
3:31:16 FTPS is FTP with TLS
3:32:43 Future
3:33:01 How to dig deeper
3:35:18 Going next?
3:38:07 You can help!
3:38:14 Questions

источник

📲 Мы в MAX

#devops #девопс

👉 @devops_star

Soft skills. Стоит ли вкладываться в софт скилы DevOps, программистам, тестировщикам?

Говорят Айтишник, особенно DevOps и SRE, должен быть улыбчивый, коммуникабельный и всё в этом роде. Зачем нужны софт скилы?

источник

📲 Мы в MAX

#devops #девопс

👉 @devops_star

RedisInsight

Redis Insight - это интуитивно понятный и эффективный графический интерфейс для Redis, позволяющий взаимодействовать с базами данных и управлять данными со встроенной поддержкой модулей Redis.

https://github.com/RedisInsight/RedisInsight

📲 Мы в MAX

#devops #девопс

👉 @devops_star

Глубокое погружение в сетевые технологии Kubernetes

На вебинаре описывается сетевая модель Kubernetes (узлы, поды, сервисы), ее преобразование в сетевые конструкции Linux, интеграция с физической сетью и оркестровка виртуальных сетевых устройств, таких как маршрутизаторы, балансировщики нагрузки и NAT-шлюзы.

https://my.ipspace.net/bin/list?id=Kubernetes#INTRO

📲 Мы в MAX

#devops #девопс

👉 @devops_star

📌45 лучших практик Terraform

Terraform — мощный инструмент для управления инфраструктурой как кодом (IaC). Однако, как и любой инструмент, его правильное использование требует соблюдения определенных лучших практик. Вот список из 45 рекомендаций, которые помогут вам писать более надежный, безопасный и управляемый код Terraform.

📌 1-10: Организация кода
1. Используйте модули – повторно используемые модули делают код более структурированным.
2. Разделяйте код на логические части – держите код читаемым.
3. Используйте удобные имена ресурсов – облегчает понимание.
4. Придерживайтесь единообразных стилей кодирования – например, форматирование через terraform fmt.
5. Организуйте переменные – отделяйте variables.tf, outputs.tf и main.tf.
6. Используйте terraform.tfvars для переопределения значений.
7. Избегайте жестко закодированных значений – используйте переменные.
8. Применяйте версии Terraform и провайдеров – required_version и required_providers.
9. Группируйте зависимости – держите их в versions.tf.
10. Следите за файлами состояния (terraform.tfstate) – не коммитьте их в репозиторий.

🔐 11-20: Безопасность
11. Храните состояние в удаленном бэкенде – например, AWS S3 с блокировкой через DynamoDB.
12. Используйте шифрование для чувствительных данных.
13. Минимизируйте использование admin -доступов – используйте least privilege.
14. Не храните секреты в коде – используйте HashiCorp Vault, AWS Secrets Manager.
15. Ограничьте доступ к terraform apply – только для CI/CD.
16. Не используйте terraform state для хранения конфиденциальных данных.
17. Используйте .gitignore для terraform.tfstate.
18. Ограничьте изменения в инфраструктуре без terraform plan.
19. Разграничивайте окружения (dev, staging, prod).
20. Всегда проверяйте код на уязвимости – например, с помощью tfsec.

⚙️ 21-30: Управление состоянием
21. Используйте terraform state list для аудита ресурсов.
22. Не редактируйте terraform.tfstate вручную.
23. Создавайте резервные копии состояния.
24. Используйте terraform state mv для реорганизации ресурсов.
25. Очищайте terraform state от удаленных ресурсов (terraform state rm).
26. Всегда обновляйте локальное состояние перед изменениями.
27. Используйте terraform import для существующих ресурсов.
28. Избегайте гонок состояний при совместной работе.
29. Используйте lock-механизмы для работы в команде.
30. Автоматизируйте управление состоянием через CI/CD.

🚀 31-40: Оптимизация
31. Минимизируйте количество зависимостей между ресурсами.
32. Используйте terraform plan перед terraform apply.
33. Оптимизируйте порядок создания ресурсов – сначала базы данных, потом приложения.
34. Следите за обновлениями Terraform и провайдеров.
35. Используйте terraform validate перед коммитом.
36. Настройте terraform fmt как pre-commit hook.
37. Используйте теги и метаданные для организации ресурсов.
38. Применяйте terraform destroy только в безопасной среде.
39. Логируйте изменения инфраструктуры.
40. Используйте count и for_each для динамического создания ресурсов.

🔄 41-45: CI/CD и автоматизация
41. Внедряйте Terraform в CI/CD процессы.
42. Автоматизируйте тестирование инфраструктуры с terratest.
43. Используйте terraform output для передачи данных в другие системы.
44. Интегрируйте Terraform с Ansible для более детальной настройки серверов.
45. Делайте регулярные ревизии кода Terraform.

https://dev.to/prakhyatkarri/terraform-45-best-practices-62l

📲 Мы в MAX

#devops #девопс

👉 @devops_star

🔍Тестовое собеседование с Head of DevOps уже завтра

18 августа(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle DevOps-разработчика.

Как это будет:
📂 Александр Хренников, Head of DevOps в KTS с опытом 14+ лет, будет задавать реальные вопросы и задачи разработчику-добровольцу
📂 Александр будет комментировать каждый ответ респондента, чтобы дать понять, чего от вас ожидает собеседующий на интервью
📂 В конце можно будет задать любой вопрос Александру

Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для DevOps-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы.

Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_devops_bot

Реклама.
О рекламодателе.

Почему Nix и NixOS становятся популярнее? Золото в мире конфигурационного менеджмента

Бросьте в меня тапком те, кто не сталкивался с ситуацией из разряда «А локально оно нормально работает» или «На проде ошибка, но на стейдже такого не было». Эти фразы стали мемами, но от этого не перестали быть болью для разработчиков и админов. И вот здесь на сцену выходит Nix — инструмент, который обещает революционизировать конфигурационный менеджмент. Полная воспроизводимость окружений, устранение дрейфа конфигураций и предсказуемость на всех этапах — звучит хорошо, не так ли? Давайте разберемся, почему Nix и NixOS набирают популярность в DevOps.

https://habr.com/ru/companies/selectel/articles/877438/

📲 Мы в MAX

#devops #девопс

👉 @devops_star