💡🐧 Быстрый совет по Linux

Команда ls — отличный инструмент командной строки для вывода списка файлов и каталогов в Linux.

Однако lsd — это еще более современная альтернатива ls. Она добавляет значки, цветной вывод и делает представление информации более удобным и наглядным.

$ lsd -lah

Если команда lsd не установлена в вашей системе по умолчанию, обратитесь к документации вашей системы для инструкций по установке.

👉 DevOps Portal

Введите в вашем терминале эту команду:

watch -d -n 1 sensors

Это отображает данные о температуре CPU, GPU, Wi-Fi, NVMe SSD и HDD в реальном времени.

Подробнее: https://cyberciti.biz/faq/howto-linux-get-sensors-information/

👉 DevOps Portal

Dockerfile: рекомендации и ошибки

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

🔹Последующие сборки не смогут повторно использовать кэш.
🔹Кэшированные файлы увеличат размер финального образа.

...но что если я скажу вам, что:

🔹Разные запуски команды docker build могут повторно использовать кэш менеджера пакетов.
🔹Кэшированные файлы не попадут в финальный образ.
🔹Кэш будет работать, даже если один из вышеуказанных слоев изменится.

И все, что для этого нужно, это использовать инструкцию RUN --mount=type=cache. Вот пример для сборки образа с Python 👆

👉 DevOps Portal

💻 Ошибки Kubernetes: подробный список (часть 1)

Ошибки Pod/контейнера

🔹CrashLoopBackOff

— Причина: Контейнер продолжает падать из-за ошибок в приложении.
— Первый шаг: Проверьте логи с помощью kubectl logs <pod> и отладьте приложение.

🔹ImagePullBackOff

— Причина: Kubernetes не может загрузить образ контейнера из реестра.
— Первый шаг: Проверьте название образа, учетные данные (если образ приватный) и убедитесь, что реестр доступен.

🔹ErrImagePull

— Причина: Kubernetes не удалось загрузить образ контейнера.
— Первый шаг: Убедитесь, что образ существует в реестре и его имя написано правильно.

🔹OOMKilled

— Причина: Контейнер превысил лимит памяти.
— Первый шаг: Увеличьте лимит памяти в спецификации pod или оптимизируйте приложение.

🔹ContainerCreating в течение длительного времени

— Причина: Проблемы с монтированием томов, образами или kubelet.
— Первый шаг: Проверьте привязки томов, статус образа и логи узла.

🔹Неудачная проверка Readiness/Liveness

— Причина: Пробы неправильно настроены или приложение не отвечает.
— Первый шаг: Проверьте настройки проб и убедитесь, что приложение готово.

Ошибки планирования Pod

🔹0/1 узлов доступны: 1 Недостаточно CPU

— Причина: Узлы кластера не имеют требуемых ресурсов CPU.
— Первый шаг: Масштабируйте кластер или отрегулируйте запросы ресурсов для pod.

🔹0/1 узлов доступны: Нет совпадений для селектора узла

— Причина: Селекторы узлов в спецификации pod не совпадают с метками узлов.
— Первый шаг: Обновите метки узлов или измените селектор узла в pod.

🔹0/1 узлов доступны: Правила Pod Affinity/Anti-affinity

— Причина: Правила размещения pod препятствуют планированию.
— Первый шаг: Проверьте и отрегулируйте правила affinity/anti-affinity в спецификации pod.

Ошибки с постоянным хранилищем

🔹VolumeMountConflict

— Причина: Несколько pod пытаются смонтировать том в режиме ReadWriteOnce.
— Первый шаг: Отрегулируйте режимы доступа к томам или конфигурацию хранилища.

🔹PersistentVolumeClaim в состоянии Pending

— Причина: Нет подходящего PersistentVolume.
—Первый шаг: Проверьте конфигурацию PV и убедитесь, что она соответствует требованиям PVC.

🔹Неудачное прикрепление тома

— Причина: Ошибка прикрепления тома к узлу.
— Первый шаг: Проверьте класс хранилища и логи облачного провайдера на наличие ошибок.

Ошибки RBAC и аутентификации

🔹Forbidden: Пользователь <user> не может просматривать ресурс <resource>

— Причина: У пользователя или сервисного аккаунта нет необходимых прав.
— Первый шаг: Создайте или обновите RoleBinding/ClusterRoleBinding.

🔹Unauthorized

— Причина: Неверный или просроченный kubeconfig.
— Первый шаг: Обновите токены, убедитесь в наличии правильных сертификатов или повторно войдите в кластер.

🔹Secret не найден

— Причина: Секрет, указанный в спецификации pod, не существует.
— Первый шаг: Создайте секрет или обновите pod, чтобы использовать существующий секрет.

Ошибки в управляющей плоскости и узлах рабочих

🔹etcdserver: запрос истек по времени

— Причина: Кластер etcd не работает должным образом или перегружен.
— Первый шаг: Проверьте логи и метрики etcd и убедитесь в правильном распределении ресурсов.

🔹Evicted

— Причина: Давление на ресурсы узла (например, недостаточно диска, памяти или CPU).
— Первый шаг: Освободите ресурсы или масштабируйте кластер.

🔹Узел испытывает давление на диск

— Причина: Недостаточно места на диске узла.
— Первый шаг: Очистите неиспользуемые образы или логи и мониторьте использование диска.

🔹Узел испытывает давление на память

— Причина: Слишком высокое использование памяти.
— Первый шаг: Определите процессы, потребляющие много памяти (top или htop), и оптимизируйте их или остановите. Рассмотрите возможность добавления памяти в узел.

🔹Узел испытывает давление по PID

— Причина: Достигнут максимальный лимит процессов (PIDs).
— Первый шаг: Увеличьте лимит PID в /etc/systemd/system.conf. Проверьте "блуждающие" процессы и оптимизируйте использование ресурсов.

(часть 2)

🔹NodeNotReady

— Причина: Узел имеет проблемы (например, истощение ресурсов, проблемы с сетью или сбой kubelet).
— Первый шаг: Проверьте логи kubelet на узле, убедитесь в его работоспособности и что он может подключиться к управляющей плоскости.

🔹Node Ready, NetworkUnavailable

— Причина: Сетевой плагин (CNI) не работает должным образом.
— Первый шаг: Проверьте логи плагина CNI (например, Calico, Flannel, Weave). Проверьте настройки сети и перезапустите pod плагина CNI.

🔹Не удается подключиться к серверу: x509: сертификат подписан неизвестным удостоверяющим центром

— Причина: Несоответствие сертификата сервера Kubernetes API и клиента.
— Первый шаг: Обновите файл ~/.kube/config или пересоздайте сертификат сервера API с действительным CA.

🔹Подключение к серверу <URL> отклонено

— Причина: Сервер API Kubernetes не работает или неправильно настроен.
— Первый шаг: Проверьте логи сервера API и убедитесь, что сервер работает на правильном порту.

Ошибки kubelet

🔹kubelet не работает должным образом

— Причина: Kubelet не может связаться с сервером API или неправильно настроен.
— Первый шаг: Проверьте логи kubelet (journalctl -u kubelet). Убедитесь, что конфигурация kubelet (/var/lib/kubelet/config.yaml) правильная.

🔹kubelet: не удалось запустить контейнер

— Причина: Проблемы с контейнерным окружением (например, Docker, containerd, CRI-O).
— Первый шаг: Проверьте логи контейнерного окружения (например, journalctl -u docker). Убедитесь, что окружение установлено и работает корректно.

🔹kubelet: не удалось смонтировать том

— Причина: Проблемы с постоянным томом или монтированием тома (например, хранилище недоступно, ошибка прав).
— Первый шаг: Проверьте, что хранилище доступно. Убедитесь в правильных правах доступа и настройках тома в спецификации pod.

🔹kubelet: узел не зарегистрирован

— Причина: Kubelet не может зарегистрировать узел в сервере API.
— Первый шаг: Проверьте логи kubelet и убедитесь, что токен kubeadm join действителен. Убедитесь, что узел может подключиться к управляющей плоскости по сети.

Ошибки контейнерного окружения

🔹ContainerRuntime не работает

— Причина: Контейнерное окружение (например, Docker, containerd) не работает или вышло из строя.
— Первый шаг: Перезапустите контейнерное окружение (systemctl restart docker или containerd). Проверьте логи на наличие ошибок.

🔹docker: не удалось загрузить образ

— Причина: Рабочий узел не может загрузить контейнерный образ из реестра.
— Первый шаг: Убедитесь, что у рабочего узла есть доступ в интернет (или к приватному реестру). Проверьте учетные данные для приватных образов.

Ошибки плагина CNI (сети)

🔹Pod застрял в ContainerCreating

— Причина: Pod не может подключиться к сети из-за проблемы с плагином CNI.
— Первый шаг: Проверьте логи плагина CNI в /var/log или с помощью kubectl logs. Убедитесь, что плагин CNI установлен и работает.

🔹Не удалось создать Pod SandBox

— Причина: Узел не смог создать пространство имен сети для pod.
— Первый шаг: Проверьте конфигурацию плагина CNI в /etc/cni/net.d/. Убедитесь, что выделение IP-адресов работает корректно.

🔹NetworkUnavailable

— Причина: Демон CNI (например, Calico, Flannel) не работает.
— Первый шаг: Перезапустите демоны CNI. Проверьте логи на наличие ошибок конкретного сетевого плагина.

👉 DevOps Portal

DevOps
MLOps
CloudOps
AlOps
DataOps
ITOps
RevOpS
FinOps
HROps
LegalOps
SysOps
BizOps
DevSecOps
ClickOps
LLMOps
ChatOps
NoOps

👉 DevOps Portal

Быстрый совет по Linux 🐧

Если вы хотите удалить пустые директории, команда find может упростить задачу:

$ find . -type d -empty -exec rmdir -v {} +

Опция -type d ищет директории, -empty выбирает пустые, а -exec rmdir {} выполняет команду rmdir, чтобы удалить их.

Команда rmdir гарантирует, что директория пуста, прежде чем удалить её.

Альтернативно, вы можете использовать эту команду для выполнения той же задачи:

$ find . -type d -empty -delete

👉 DevOps Portal

💻 Совет по устранению неполадок в Kubernetes: Устранение проблем с сетью.

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

Лично я предпочитаю использовать инструмент "Netshoot", основанный на Docker-образе. В нем есть большинство необходимых инструментов (ping, curl, dig, nmap, netcat и т. д.), и его можно запустить как временный под. Он будет работать, пока вы им пользуетесь, а как только вы выйдете из пода, тот сразу же будет удален.

Команда для его запуска:
❯ kubectl run tmp-shell --rm -i --tty --image nicolaka/netshoot --namespace=<namespace> -- /bin/bash

👉 DevOps Portal

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

В статье подробно рассматриваются механизмы назначения Pod'ов на узлы в Kubernetes.

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

👉 Ссылка на статью

👉 DevOps Portal

Docker против Kubernetes: В чем разница?

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

— Docker

🔹 Платформа для контейнеризации.
🔹 Упаковывает приложения и зависимости в контейнеры.
🔹 Обеспечивает переносимость между средами.
🔹 Запускает контейнеры на одном хосте.
🔹 Используется в CI/CD-пайплайнах для автоматизации развёртывания.

— Kubernetes

🔹 Система оркестрации контейнеров.
🔹 Управляет контейнеризированными приложениями на большом масштабе.
🔹 Обрабатывает развёртывание, масштабирование и сетевые взаимодействия.
🔹 Распределяет рабочие нагрузки между несколькими узлами.
🔹 Оптимизирован для микросервисов и облачно-ориентированных приложений.

— Как они работают вместе

Docker создает и запускает контейнеры. Kubernetes оркестрирует и управляет ими в большом масштабе. Вместе они позволяют создавать масштабируемые и устойчивые облачные системы и DevOps-процессы.

— Нужны ли вам оба инструмента?

Если вы запускаете несколько контейнеров, достаточно Docker. Если вам нужны высокая доступность, авто-масштабирование и самовосстановление, следующий шаг — Kubernetes.

👉 DevOps Portal

Строим контейнерные образы как профи 😎

Множество ресурсов по созданию образов:
🔹5 учебных пособий по композиции образов, выбору базового образа, многоступенчатым сборкам и образам без дистрибутива.
🔹12 практических задач для создания и отладки образов.

Посмотреть здесь: https://labs.iximiuz.com/skill-paths/build-container-images

👉 DevOps Portal

Это репозиторий примеров из книги "Ansible for DevOps" Джеффа Гирлинга.

Он демонстрирует использование Ansible для автоматизации серверов и управления конфигурациями, с реальными примерами и плейбуками

👉 https://github.com/geerlingguy/ansible-for-devops

👉 DevOps Portal

💡 Быстрый совет по Docker

Хотите узнать, сколько дискового пространства занимают образы, контейнеры, локальные тома или кэш сборки?

Используйте команду:

docker system df

👉 DevOps Portal

Репозиторий с кучей полезных материалов и информации, связанных с DevOps

Содержит ресурсы по таким темам, как Linux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure и GC

👉 DevOps Portal

Структура манифеста развертывания Kubernetes: объяснение

В YAML-файле развертывания Kubernetes определяется, как приложение должно быть развернуто и управляться в кластере Kubernetes.

Ниже приведена структура YAML с пояснениями.

— Объяснение ключевых разделов

🔸apiVersion & kind: Определяет, что этот ресурс является развертыванием и использует API Kubernetes apps/v1.
🔸metadata: Содержит информацию, такую как имя и метки для организации приложения.
🔸spec.replicas: Определяет желаемое количество работающих экземпляров (Pod'ов).
🔸spec.selector.matchLabels: Гарантирует, что развертывание управляет только Pod'ами с соответствующими метками.
🔸spec.template:
- Определяет шаблон Pod'а (его metadata и spec).
- Раздел containers описывает контейнер, включая образ, порты и ресурсы.
- Можно также задать переменные среды, монтирование томов и лимиты ресурсов.
🔸spec.strategy: Управляет стратегией обновления развертывания (RollingUpdate или Recreate).
🔸volumes: Позволяет определить постоянное хранилище, такое как ConfigMaps, Secrets или Persistent Volumes.

— Дополнительные параметры
🔸Проверки работоспособности: Liveness & Readiness Probes
🔸Управление размещением: Affinity & Node Selectors
🔸Предварительная обработка: Init Containers

👉 DevOps Portal

💡 Совет по Linux

Получите контекст вашего поиска с помощью grep, используя параметр -C:

$ grep -C3 filename

Это покажет 3 строки до и после найденного совпадения.

Очень помогает при анализе логов 😎

👉 DevOps Portal

🖥 Основные компоненты Docker: объяснение

Docker решает проблему «у меня на машине работает» 😱

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

Docker решает проблему «у меня на машине работает» и упрощает развертывание приложений, инкапсулируя их вместе с зависимостями в стандартизированные, масштабируемые и изолированные контейнеры (контейнеризация).

В основе Docker лежит несколько ключевых компонентов.

Разбираясь в них, вы получите прочную базу понимания. Давайте разберем их!

🔸Образы (Images)
Образы — это неизменяемые шаблоны, используемые для создания контейнеров. Они создаются с помощью инструкций в Dockerfile или загружаются из Docker-реестра, такого как Docker Hub.

🔸Контейнер (Container)
Контейнер — это запущенный экземпляр образа. Это легковесный, автономный пакет, содержащий все необходимое для работы приложения.

🔸Dockerfile
Файл, содержащий последовательность команд для создания образа Docker.

🔸Docker Engine
Docker Engine отвечает за запуск и управление контейнерами. Он состоит из демона Docker и CLI-инструмента, взаимодействующего с ним через REST API.

🔸Docker Daemon
Фоновый сервис, управляющий объектами Docker. Он обрабатывает API-запросы и управляет образами, контейнерами, сетями и томами хранения.

🔸Docker Registry
Репозитории для хранения и распространения образов Docker. Реестры могут быть публичными или частными. По умолчанию Docker использует публичный реестр Docker Hub.

🔸Сеть Docker (Docker Network)
Контейнеры работают в сетях, что позволяет им взаимодействовать друг с другом и с внешним миром. Сеть предоставляет коммуникационный шлюз между контейнерами на одном или разных хостах.

🔸Тома (Volumes)
Тома позволяют сохранять данные вне контейнера и делиться ими между контейнерными инстансами, даже после удаления контейнера. Они обеспечивают независимость данных от жизненного цикла контейнера.

Все эти компоненты взаимосвязаны, создавая удобную систему для автоматизации развертывания, масштабирования и управления приложениями. Благодаря этому Docker стал мощным и важным инструментом в современной разработке программного обеспечения.

👉 DevOps Portal

💡 Быстрый совет по Linux 🐧

Когда вы запускаете программу в терминале или по SSH, она завершится сразу после закрытия сессии терминала (когда вы выйдете из него) или при разрыве соединения.

Чтобы избежать этого и сохранить выполнение программы и всех её процессов, используйте команду nohup (сокращение от no hangup – «без зависания»). Она игнорирует все сигналы разрыва соединения, позволяя процессу продолжать работу даже при закрытии терминала.

Например, чтобы сжать большой объем данных с помощью команды tar и гарантировать, что процесс не прервётся при случайном закрытии терминального окна, выполните команду:

$ nohup tar -cf archive.tar file1 file2

Также nohup создаёт файл nohup.out, в который записывает вывод команды:

$ cat nohup.out

Альтернативно, можно использовать tmux, disown или screen.

👉 DevOps Portal

💡Совет по Bash-скриптам

Вы можете использовать ловушку DEBUG, чтобы шаг за шагом проходить через bash-скрипт, давая вам возможность проверять каждую строку перед её выполнением — это идеально для отладки!

— Вот как это работает:

Команда trap с параметром DEBUG срабатывает сразу перед выполнением каждой строки, приостанавливая выполнение, чтобы вы могли решить, хотите ли продолжить. Это как интерактивное «пошаговое выполнение» вашего bash-скрипта.

В отличие от sh -x, который выводит каждую строку без остановки, этот метод позволяет вам контролировать выполнение каждой команды перед её запуском.

Ловушка DEBUG не является настоящим сигналом, а представляет собой специальную функцию (псевдосигнал), которая срабатывает перед каждой строкой скрипта, что удобно для понимания поведения скрипта построчно.

Вы также можете изучить похожие псевдосигналы, такие как EXIT, который выполняет команды перед завершением скрипта; RETURN, который срабатывает при возврате из функции или после того, как скрипт был загружен (с помощью source или .); и ERR, который обрабатывает команды, возвращающие ненулевой код завершения при активированном set -e.

👉 DevOps Portal

Как работает преобразование сетевых адресов (NAT)

Преобразование сетевых адресов (NAT) — это фундаментальная технология в современных сетях, которая позволяет устройствам в частной сети обмениваться данными с внешними сетями, такими как Интернет, используя один публичный IP-адрес. Эта возможность критически важна для экономии ограниченных ресурсов IPv4-адресов и повышения безопасности сети. Рассмотрим, как работает NAT на основе приведенной инфографики.

— Основы NAT

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

— Компоненты и процесс

1. Частная сеть и публичный IP:

🔹Устройства в частной сети получают частные IP-адреса (например, 192.168.3.6, 192.168.3.7, 192.168.3.8).
🔹Маршрутизатор, выполняющий NAT, имеет частный IP-адрес (например, 192.168.3.0/24) на своем внутреннем интерфейсе и публичный IP-адрес (например, 200.100.10.1) на внешнем интерфейсе, предоставленный поставщиком Интернет-услуг (ISP).

2. Преобразование пакетов:

🔹Когда устройство (например, 192.168.3.6) хочет общаться с внешним сервером (например, 65.44.21.24) через Интернет, оно отправляет пакет с своим частным IP-адресом в качестве источника.
🔹Маршрутизатор с включенным NAT перехватывает этот пакет. Прежде чем отправить его в назначение, маршрутизатор заменяет частный IP-адрес (192.168.3.6:5733) на свой публичный IP-адрес (200.100.10.1:5733). Этот процесс позволяет пакету пройти через Интернет, поскольку он не маршрутизирует частные IP-адреса.

3. Поддержание сеансов:

🔹Маршрутизатор поддерживает таблицу NAT для отслеживания активных сеансов. Эта таблица содержит соответствия между внутренними частными IP-адресами и портами и внешними публичными IP-адресами и портами.
🔹Например, таблица NAT может отображать соответствие 192.168.3.6:5733 -> 200.100.10.1:5733, что позволяет маршрутизатору корректно перенаправлять ответы обратно на исходное устройство в частной сети.

4. Обратное преобразование пакетов:

🔹Когда внешний сервер (65.44.21.24) отвечает, он отправляет пакеты на публичный IP-адрес (200.100.10.1:5733).
🔹NAT-маршрутизатор перехватывает эти входящие пакеты, обращается к таблице NAT и преобразует адрес назначения обратно в частный IP-адрес (192.168.3.6:5733), прежде чем отправить его соответствующему внутреннему устройству.

— Преимущества NAT

🔹Сохранение IP-адресов: NAT позволяет нескольким устройствам в локальной сети использовать один публичный IP-адрес, что значительно уменьшает количество требуемых IP-адресов.
🔹Безопасность: NAT скрывает внутренние IP-адреса сети, обеспечивая дополнительный уровень безопасности, предотвращая прямой доступ к внутренним устройствам из внешней сети.

— Заключение

NAT — это важная технология, которая помогает эффективно использовать IP-адреса и повышать безопасность сети. Преобразуя частные IP-адреса в публичные и управляя этими соответствиями, NAT обеспечивает бесперебойную связь между частными сетями и Интернетом. Эта функциональность незаменима в условиях ограниченных ресурсов IP-адресов и повышенных требований к безопасности.

👉 DevOps Portal