Создание кластера Kubernetes v1.28 с Kubeadm на AWS с помощью Terraform и Ansible

https://www.youtube.com/watch?v=RkuBsRqgvuE

#devops #девопс

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

Практическое руководство по реализации Observability в DevOps

https://faun.pub/a-practical-guide-to-observability-in-devops-950cbf93f111

#devops #девопс

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

Registry.k8s.io

Этот проект реализует бэкенд для registry.k8s.io, реестра образов контейнеров Kubernetes.

https://github.com/kubernetes/registry.k8s.io


#devops #девопс

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

Как устранять неполадки в приложениях Kubernetes

Это руководство по устранению неполадок в приложениях, развернутых на кластере Kubernetes. Оно основано на моем опыте работы с этой технологией после перехода с Docker в начале 2017 года.

Существует множество сторонних инструментов и методик, но я хочу остановиться на тех, которые можно найти практически на каждом компьютере, или на CLI, которые можно быстро загрузить для MacOS, Windows или Linux.

https://blog.alexellis.io/troubleshooting-on-kubernetes/

#devops #девопс

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

0b10 лет спустя: нырок в девопс

Привет! На связи автор статьи двухлетней давности "Пожалуйста, прекратите называть админов девопсами". В ней, если помните, я ловил пескарей в процессе поиска работы офигевал от несоответствия реального мира и моих онтологических ожиданий. Золотые были денёчки, с тех пор мир изменился - и вот, с учётом полученного за прошедшее время опыта я хотел бы оглянуться, посмотреть назад и понять, выдержали ли мои прошлые соображения проверку временем.

Рефлексия, как и любая обратная связь, на мой взгляд - мега-полезная штука, если уметь ею пользоваться и не доводить себя в процессе до тревожных состояний.

Практически сразу после выхода той статьи со мной связался целый технический директор небольшой IT-компании и во время интервью заявил, что разделяет взгляд на описанное, сходу предложив мне трудоустройство. Было анонсировано желание, чтобы я провёл аудит инфраструктуры, сделал заключение о её состоянии и предложил роадмап по приведению в порядок. Гово

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

#devops #девопс

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

Kubeshark

Анализатор API-трафика для Kubernetes, обеспечивающий видимость уровня протокола K8s в режиме реального времени, перехват и мониторинг всего трафика и полезной нагрузки, поступающей в контейнеры, подсистемы, узлы и кластеры, а также исходящей от них. Вдохновленный Wireshark, специально созданный для Kubernetes

https://github.com/kubeshark/kubeshark

#devops #девопс

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

Argocd-vault-replacer

Плагин для Argo CD, позволяющий заменять простановки в манифестах Kubernetes на секреты, хранящиеся в Hashicorp Vault.

https://github.com/crumbhole/argocd-vault-replacer

#devops #девопс

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

System Design 101

О сложных системах простыми словами.

В шпаргалке на высоком уровне рассматриваются такие вещи, как протоколы коммуникации, DevOps, CI/CD, архитектурные паттерны, базы данных, кэширование, микросервисы (и монолиты), платежные системы, Git, облачные сервисы etc. Особую ценность представляют диаграммы — рекомендую уделить им пристальное внимание. Полагаю, шпаргалка будет интересна всем, кто хоть как-то связан с разработкой программного обеспечения и, прежде всего, веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий, терминологии, логики/алгоритмов работы систем (в рамках того, что по этому поводу содержится в оригинале), а также в обнаружении очепяток.

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

#devops #девопс

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

Exit Codes в контейнерах и Kubernetes

Если вы являетесь пользователем Kubernetes, то сбои в работе контейнеров являются одной из наиболее распространенных причин исключений в pod, и понимание кодов выхода контейнеров может помочь вам найти первопричину сбоев в pod при устранении неполадок.

https://komodor.com/learn/exit-codes-in-containers-and-kubernetes-the-complete-guide/

#devops #девопс

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

Tutorials - Ron Nathaniel: How To Troubleshoot and Monitor Applications using OpenTelemetry

OpenTelemetry — это бесплатный опенсорсный Observability Protocol, который находится на прикладном уровне и экспортирует трассировки, метрики и журналы в серверную часть для наблюдения. Он полезен для разработчиков с точки зрения time-to-detection и time-to-resolution ошибок и неполадок, возникающих на прикладном уровне. Процесс варьируется от обнаружения и оповещения о возникших ошибках (таких как TypeError) до обнаружения того, что конкретный микросервис работал в два раза дольше обычного, вплоть до просмотра выходных данных сервиса и сравнения их с ожидаемыми выходными данными, чтобы найти ошибку в логике работы.

Руководство предназначено для начинающих специалистов и требует минимальный опыт работы с Requests и Flask. Опыта работы с OpenTelemetry не требуется. Важно только иметь четкое представление о трассировках, метриках и журналах.

https://www.youtube.com/watch?v=np_YsjQAcEw

#devops #девопс

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

Советы по Kubernetes!

15 советов и рекомендаций по работе с Kubernetes, о которых должен знать каждый администратор Kubernetes 👇⚓️

1/ 🔍 Мастерство работы с пространствами имен:
Эффективное использование пространств имен позволяет упорядочить кластеры. Логическая группировка ресурсов, изоляция сред и упрощение управления.

2/ 🚦 Квоты и лимиты ресурсов:
Установите квоты на ресурсы, чтобы предотвратить их перегрузку. Используйте лимиты, чтобы обеспечить справедливое распределение ресурсов и избежать влияния одного недобросовестного стручка на другие.

3/ 🔄 Срочные обновления FTW:
Используйте обновление по расписанию при развертывании. Это обеспечивает минимальное время простоя за счет постепенной замены экземпляров, что делает обновление более плавным и удобным.

4/ 🛡️ RBAC Best Practices:
Тонкая настройка управления доступом с помощью ролевого управления доступом (RBAC). Предоставление наименьших привилегий, регулярный аудит ролей и обеспечение безопасности кластера.

5/ 📚 Документация имеет значение:
Kubernetes имеет обширную документацию. Ознакомьтесь с ней! Глубокое понимание особенностей позволит сэкономить время и избежать головной боли.

6/ 💻 Imperative vs. Declarative:
Знайте, когда следует использовать императивные команды (kubectl run), а когда - декларативные YAML-файлы. Декларативная конфигурация более удобна в обслуживании и масштабируема.

7/ 🔄 Pod Disruption Budgets:
Реализовать PodDisruptionBudgets для контроля случайных сбоев, таких как обновление или обслуживание. Сохраняйте стабильность!

8/ 🚨 Мониторинг и оповещения:
Настройте надежный мониторинг и оповещения. Prometheus и Grafana - ваши друзья. Раннее обнаружение предотвращает катастрофы.

9/ 🛠️ Мудрость диаграмм Helm:
Используйте диаграммы Helm для упаковки, версионирования и управления приложениями Kubernetes. Это упрощает сложные развертывания.

10/ 🔄 CronJobs для запланированных задач:
Используйте CronJobs для автоматизации повторяющихся задач в кластере. Запланированное обслуживание, резервное копирование и очистка стали проще!

11/ 🧹 Очистка ресурсов:
Регулярный аудит и очистка неиспользуемых ресурсов. Избегайте разрастания ресурсов и поддерживайте кластер.

12/ 🚀 Пользовательские определения ресурсов (CRD):
Расширяйте API Kubernetes своими собственными ресурсами. CRD позволяют определять пользовательские объекты и контроллеры для специализированных случаев использования.

13/ 🔗 Сетевые политики:
Определение сетевых политик для контроля взаимодействия между капсулами. Повышение уровня безопасности и ограничение потенциальных возможностей для атак.

14/ 🔄 Горизонтальное автомасштабирование Pod:
Включите автомасштабирование для своих развертываний. Пусть Kubernetes автоматически регулирует количество pod-ов в зависимости от использования ресурсов или пользовательских показателей.

15/ 🚛 Persistent Volumes:
Понимание и использование Persistent Volumes и Persistent Volume Claims. Обеспечение сохранности данных и эффективное управление хранением.

#devops #девопс

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

Технологический стек Netflix - CI/CD Pipeline


Эта статья основана на материалах многих инженерных блогов Netflix и проектов с открытым исходным кодом.

Планирование: Netflix Engineering использует JIRA для планирования и Confluence для документирования.

Код: Java - основной язык программирования для сервисов бэкенда, другие языки используются для различных задач.

Сборка: Для сборки в основном используется Gradle, а для поддержки различных вариантов использования создаются плагины Gradle.

Упаковка: Пакет и зависимости упаковываются в машинный образ Amazon (AMI) для выпуска.

Тестирование: Тестирование подчеркивает ориентацию продакшен-культуры на создание хаос-инструментов.

Развертывание: Для развертывания Netflix использует самостоятельно созданный Spinnaker.

Мониторинг: Метрики мониторинга централизованы в Atlas, а для выявления аномалий используется Kayenta.

Отчет об инцидентах: Инциденты рассылаются в соответствии с приоритетом, а для их обработки используется PagerDuty.

#devops #девопс

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

Docker vs. Kubernetes. Что мы должны использовать?

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

Что такое Kubernetes?
Kubernetes, также известная как K8s, - это система с открытым исходным кодом для автоматизации развертывания, масштабирования и управления контейнерными приложениями. Она группирует контейнеры, из которых состоит приложение, в логические блоки для удобства управления и обнаружения в кластере машин. Для запуска контейнеров в Kubernetes используются не Docker Engine, а такие среды выполнения контейнеров, как containerd и CRI-O.

Чем они отличаются?
Docker ориентирован на автоматизацию создания и развертывания отдельных контейнеров на одном узле. Хотя он может управлять коллекциями контейнеров с помощью Docker Swarm, он более ограничен по сравнению с Kubernetes с точки зрения масштабируемости и возможностей.

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

Таким образом, Docker отлично справляется с управлением контейнерами на одной системе, а Kubernetes предназначен для управления и масштабирования многоконтейнерных приложений в кластерах.

#devops #девопс

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

Go Clouddriver: масштабирование Spinnaker до 1000 кластеров Kubernetes в The Home Depot

В августе 2019 года The Home Depot выбрала Spinnaker в качестве корпоративного решения непрерывного развертывания (CD) для целей Google Cloud Platform (GCP). Мы планировали использовать Spinnaker в качестве инструмента для развертывания Kubernetes и App Engine. В то время у нас было несколько сотен проектов GCP и пара сотен кластеров Kubernetes, которые в последующие месяцы постепенно начали интегрироваться в Spinnaker. На этом пути стояла одна большая проблема: чем больше провайдеров Kubernetes мы подключили, тем больше микросервис Spinnaker Clouddriver требовал все большего количества вычислительных ресурсов. Когда мы охватили около 500 провайдеров Kubernetes, Clouddriver использовал около 100 процессоров и 250 ГБ памяти. Учитывая перспективу более чем удвоения числа поставщиков Kubernetes, мы знали, что нам нужно найти решение этой дилеммы, поскольку такой рост ресурсов был неустойчивым.

https://blog.spinnaker.io/go-clouddriver-scaling-spinnaker-to-1000-kubernetes-clusters-at-the-home-depot-c2dc1a05be8e

#devops #девопс

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

SRE Roadmap

Дорожная карта, чтобы стать SRE (концепции > инструменты)

https://github.com/teivah/sre-roadmap

#devops #девопс

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

Список замечательных программных продуктов для Devops

https://github.com/awesome-soft/awesome-devops

#devops #девопс

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

Наш опыт интеграции внешних DevOps-команд в команды клиента: этапы, процессы, трудности, неочевидные нюансы

Привет! На связи Никита Ветров, менеджер проектов компании «Флант». Сегодня я поделюсь тем, как устроена услуга DevOps as a Service с точки зрения процессов взаимодействия наших команд с клиентами.

У внутренней и внешней DevOps-команд одинаковые обязанности. Они отвечают за то, чтобы все стабильно работало. Например, следят за тем, чтобы приложения исправно функционировали, а при сбоях исправляют ошибки. Но, чтобы выполнять эти обязанности, DevOps-команда должна быть сформирована и готова к задачам. В этом и есть основное отличие внешней команды от внутренней.

https://habr.com/ru/companies/flant/articles/775646/

#devops #девопс

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

Б значит не Безумие, а Безопасность: часть 1

Читать про кибербезопасность, безопасность инфраструктуры и DevSecOps интересно, но еще интереснее (и полезнее) рассматривать эти темы на конкретных примерах.

В рамках серии статей Алексей, DevOps-инженер компании Nixys, делится реальным опытом и в первой части рассказывает про работу над проектом, который пришел с таким ТЗ:

1. Замкнутый контур;

2. Отсутствие CVE во всех используемых продуктах;

3. Контроль безопасности уже имеющейся инфраструктуры;

4. Контроль доступа до среды;

5. Автоматизация процессов.

➡️ Давайте посмотрим, что из этого вышло

#devops #девопс

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