По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Работая в экосистеме DevOps, скоро понимаешь, насколько важно иметь инструменты DevOps для уменьшения ручной работы. Для каждого этапа DevOps есть несколько наборов инструментов с различными функциональными возможностями.
Kubernetes является одним из обязательных, если вы работаете в домене DevOps и запускаете свои приложения внутри контейнеров. Для большей функциональности Kubernetes можно использовать сотни различных инструментов. Говоря об инструментах имеется ввиду утилиты для упрощения управления, улучшения безопасности, различные панели и средства мониторинга Kubernetes кластеров.
1. Helm
Helm - это менеджер пакетов для Kubernetes, который позволяет легко управлять приложениями и службами, которые используются во многих различных сценариях, облегчая их развертывание в типичном кластере Kubernetes. Используя Helm, вы можете найти, поделиться и использовать программное обеспечение, которое построено для Kubernetes.
Он использует диаграммы, называемые Helm Charts, для определения, установки и обновления сложных приложений Kubernetes.
Функции Helm:
Отображает состояние всех Kubernetes приложений с помощью диаграмм
Использует настраиваемые крючки, чтобы легко проводить обновления.
Диаграммы можно использовать на общедоступных или частных серверах.
Простой откат к предыдущему состоянию с помощью одной команды
Повышение производительности разработчиков и эксплуатационной готовности
2. Flagger
Flagger - это оператор прогрессивной доставки для Kubernetes.
Он автоматизирует продвижение канареечного развертывания с помощью Istio, App Mesh, Nginx, Linkerd, Contour, Gloo, Skipper для маршрутизации трафика и Prometheus для анализа канарей. При канареечном развертывании выпуски развертываются для небольшой группы пользователей, тестируются, если работает нормально, то выпуски развертываются для всех.
Он использует сетку служб, которая выполняется в кластере, для управления трафиком между развертыванием. Для переноса трафика в канарейку он измеряет такие показатели производительности, как средняя продолжительность запросов, частота успешных запросов HTTP, работоспособность модуля и т.д.
Flagger может выполнять автоматизированный анализ приложений, продвижение и откат для нескольких стратегий развертывания, таких как Canary, A/B-тестирование, Blue/Green-развертывание.
3. Kubewatch
Kubewatch это наблюдатель с открытым исходным кодом для Kubernetes, который отправляет уведомление через Slack.
Он написан на языке Go и разработан Bitnami Labs. Он используется для мониторинга ресурсов Kubernetes и уведомляет, есть ли какие-либо изменения.
Установить Kubewatch можно через kubectl или с помощью диаграмм helm. В нем легко разобраться и имеет очень простой в использовании интерфейс. Кроме Slack, он также поддерживает HipChat, Mattermost, Flock, webhook и SMTP.
В зависимости от того, какой Kubernetes кластер вы хотите отслеживать, вы можете установить значение true или false для этих ресурсов в файле ConfigMap. После установки конфигурации kubewatch и запуска модуля вы начнете получать уведомления о событии Kubernetes, как показано ниже.
4. Gitkube
Gitkube - это инструмент, который использует git push для создания и развертывания докер образов на Kubernetes. Имеет три компонента - Remote, gitkube-контроллер, gitkubed. Remote состоит из пользовательских ресурсов, управляемых gitkube-контроллером. gitkube-controller отправляет изменения в gitkubed, который затем строит образ докера и развертывает его.
Особенности Gitkube:
Простота установки, подключения и развертывания
Обеспечивает управление доступом на основе ролей для обеспечения безопасности
Проверки подлинности с помощью открытого ключа
Поддерживается пространство имен для множественной аренды
Никаких дополнительных зависимостей, кроме kubectl и git
5. kube-state-metrics
kube-state-metrics - сервис, который генерирует метрики объекта состояния, прослушивая сервер API Kubernetes. Он используется для проверки работоспособности различных объектов, таких как узлы, модули, пространства имен и развертывания. Он предоставляет необработанные, немодифицированные данные из API Kubernetes.
Ниже приведена информация, предоставленная kube-state-metrics:
Задания Cron и статус задания
Состояние модулей (готовность, выполнение и т.д.)
Запросы на ресурсы и их диапазон
Пропускная способность узла и его состояние
Спецификация наборов реплик
6. Kamus
Kamus - это инструмент GitOps с открытым исходным кодом, который используется для шифрования и дешифрования секретных ключей для приложений Kubernetes. Зашифрованные ключи, которые делает Kamus, могут быть расшифрованы только приложениями, работающими в кластере Kubernetes. Для шифрования ключей используется AES, Google Cloud KMS, Azure KeyVault. Начать работу с Kamus можно с помощью helm.
Kamus поставляется с двумя утилитами - Kamus CLI и Kamus init container. Kamus CLI используется для интеграции с шифрованным API, а контейнер Kamus init - для интеграции с расшифровкой API.
По умолчанию, пароли в Kubernetes закодированы в base64 и не зашифрованы. Поэтому, из соображений безопасности, нельзя держать такие ключи на. Любой, кто имеет доступ к репозиторию, сможет использовать эти секреты. Следовательно, необходимо правильное решение для шифрования/дешифрования, как, например, Kamus. Он также предоставляет модель угроз, которая учитывает угрозы и делает секреты безопасными.
7. Untrak
Untrak - инструмент с открытым исходным кодом, используемый в Kubernetes для поиска неотслеживаемых ресурсов и сбора мусора. Он помогает находить и удалять файлы из кластера, которые не отслеживаются.
После ввода манифестов в конвейер CI/CD с использованием шаблона kubectl apply или helm Kubernetes не знает, когда объект будет удален из репозитория. После удаления объектов они не отслеживаются в процессе доставки и по-прежнему находятся в кластере Kubernetes.
Он выполняет команду внутренне, используя простой конфигурационный файл untrak.yaml, чтобы найти ресурсы, которые больше не являются частью управления исходным кодом.
8. Weave Scope
Weave Scope предназначена для визуализации, мониторинга и устранения неполадок Docker и Kubernetes.
Он отображает всю структуру контейнерного приложения сверху вниз, и полную инфраструктуру, с помощью которой вы можете легко выявить любые проблемы и диагностировать их.
Выполнение приложений микросервисной архитектуры в контейнерах докеров не так просто. Компоненты здесь очень динамичны и трудно поддаются мониторингу. С помощью Weave Scope можно легко устранять утечки памяти и контролировать потребление ЦП, визуализировать узкие места сети.
Функции Weave Scope:
Помогает отслеживать контейнеры докеров в режиме реального времени
Простая навигация между процессами, выполняемыми в контейнерах
Показывает хост или службу использования ЦП и памяти
Перезапуск, остановка или приостановка контейнеров с помощью интерфейса командной строки, не выходя из окна браузера Weave Scope.
Поддержка пользовательских подключаемых модулей для получения более подробной информации о контейнерах, процессах и хостах
9. Kubernetes Dashboard
Kubernetes Dashboard - веб-интерфейс, предоставляемый компанией Kubernetes. Он используется для развертывания, устранения неполадок и управления контейнерным приложением в кластере Kubernetes. Он предоставляет всю информацию о кластере, такую как сведения о узлах, пространствах имен, ролях, рабочих нагрузках и т.д.
Можно использовать helm для развертывания панели управления Kubernetes или воспользоваться простой командой kubectl:
kubectl apply - https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.4/aio/deploy/recommended.yaml
10. Kops
Kops, который расшифровывается как Kubernetes Operations - это проект с открытым исходным кодом, используемый для создания готовых к запуску в производственной среде кластеров Kubernetes. Kops, в первую очередь, можно использовать для развертывания кластеров Kubernetes на AWS и GCE.
Небольшой кластер Kubernetes легко создать и обслуживать, но при масштабировании кластера добавляется множество конфигураций, и становится трудно управлять им. Kops - это инструмент, который помогает решать подобные задачи. Он использует подход, основанный на настройке, при котором кластер всегда находится в актуальном состоянии и в безопасености.
Kops также имеет множество сетевых бэкэндов, и выбор одного из них, в зависимости от варианта использования, упрощает настройку различных типов кластеров.
11. cAdvisor
cAdvisor - это инструмент с открытым исходным кодом для мониторинга контейнера. Он используется для чтения характеристик производительности и использования ресурсов контейнеров, работающих в кластере.
Он работает на уровне узла и может автоматически обнаруживать все контейнеры, работающие на определенном узле, и собирать статистику использования памяти, файловой системы, ЦП и сети. Он предоставляет веб-интерфейс, который отображает динамические данные всех контейнеров в кластере.
Для начала работы с cAdvisor необходимо запустить его docker образ google/cadvisor, а затем получить к нему доступ по адресу http://localhost:8080 в веб-браузере.
12. Kubespray
Kubespray - это бесплатный инструмент, который был создан путём объединения playbooks Ansible и Kubernetes. Используется для управления жизненным циклом кластера Kubernetes.
С помощью Kubespray можно быстро развернуть кластер и настроить все параметры реализации кластера, такие как режимы развертывания, сетевые плагины, конфигурация DNS, версии компонентов, методы создания сертификатов и т.д.
Для начала работы кластера достаточно запустить один единственный ansible-playbook. Вы можете легко масштабировать или обновлять кластер Kubernetes.
13. K9s
K9s - это терминальный инструмент с открытым исходным кодом, и его утилита панели мониторинга может делать все, что делает веб-интерфейс Kubernetes. Он используется для навигации, наблюдения и управления приложением, развернутым в кластере Kubernetes.
K9s функции:
Отслеживание кластера в реальном времени
Настройка отображения для каждого ресурса
Глубокий анализ проблем с ресурсами кластера
Поддерживает управление доступом на основе ролей
Встроенные эталонные тесты для проверки производительности ресурсов
14. Kubetail
Kubetail - это простой сценарий bash, который используется для агрегирования журналов из нескольких модулей в одном потоке.
Последняя версия Kubetail также имеет функции выделения и фильтрации. Эта функция позволяет выделять нужные части логов отдельным цветом. Используя homebrew, можно установить Kubetail с помощью одной команды. Чтобы упростить работу Kubetail можно добавить значения, как KUBETAIL_NAMESPACE, KUBETAIL_TAIL, KUBETAIL_SKIP_COLORS и т.д. в переменные среды.
15. PowerfulSeal
PowerfulSeal - мощный инструмент хаос-инжиниринга с открытым исходным кодом, написанный на языке python для кластеров Kubernetes.
Хаос-инжиниринг используется для того, чтобы проверить отказоустойчивость системы, ее способность справляться с проблемными ситуациями в производственной среде. Он вводит в кластер Kubernetes ошибки, чтобы выявить проблемы в нем как можно раньше.
Создателей PowerfulSeal вдохновил Netflix Chaos Monkey и она используется для повышения устойчивости Kubernete. Используя Seal, инженеры сознательно пытаются нарушить работу кластера, чтобы проверить, как система реагирует.
Seal работает в трех режимах - автономный, интерактивный, и режим меток.
В автономном режиме он выполняет сценарии, считывая предоставленный файл политики. В интерактивном режиме он рассказывает о компонентах кластера, которые вручную пытаются разорвать. В режиме меток целевые объекты в кластере, такие как модули, уничтожаются с помощью меток.
16. Popeye
Popeye - это утилита для очистки кластеров Kubernetes.
Он сканирует весь кластер и сообщает о проблемах, связанных с конфигурациями и ресурсами. Это помогает применять лучшие практики в кластере Kubernetes, чтобы избежать распространенных проблем.
Эта утилита доступна для Windows, Linux и macOS. В настоящее время он работает только с узлами, модулями, пространствами имен, службами. С помощью Popeye можно легко идентифицировать мертвые и неиспользуемые ресурсы, несоответствия портов, правила RBAC, использование метрик и многое другое.
В семиуровневой модели OSI на различных уровнях имеются разные типы адресов. На канальном это MAC-адрес, а на сетевом это IP-адрес. И для того чтобы установить соответствие между этими адресами используется протокол Address Resolution Protocol – ARP. Именно о нем мы поговорим в этой статье.
Адресация
Адреса 2-го уровня используются для локальных передач между устройствами, которые связаны напрямую. Адреса 3-го уровня используются устройств, которые подключены косвенно в межсетевой среде. Каждая сеть использует адресацию для идентификации и группировки устройств, чтобы передачи прошла успешно. Протокол Ethernet использует MAC-адреса, которые привязаны к сетевой карте.
Чтобы устройства могли общаться друг с другом, когда они не находятся в одной сети MAC-адрес должен быть сопоставлен с IP-адресом. Для этого сопоставления используются следующие протоколы:
Address Resolution Protocol (ARP)
Reverse ARP (RARP)
Serial Line ARP (SLARP)
Inverse ARP (InARP)
Address Resolution Protocol
Устройству 3го уровня необходим протокол ARP для сопоставления IP-адреса с MAC-адресом, для отправки IP пакетов. Прежде чем устройство отправит данные на другое устройство, оно заглянет в свой кеш ARP где хранятся все сопоставления IP и MAC адресов, чтобы узнать, есть ли MAC-адрес и соответствующий IP-адрес для устройства, которому идет отправка. Если записи нет, то устройство-источник отправляет широковещательное сообщение каждому устройству в сети чтобы узнать устройству с каким MAC-адресом принадлежит указанный IP-адрес. Все устройства сравнивают IP-адрес с их собственным и только устройство с соответствующим IP-адресом отвечает на отправляющее устройство пакетом, содержащим свой MAC-адрес. Исходное устройство добавляет MAC-адрес устройства назначения в свою таблицу ARP для дальнейшего использования, создает пакет с новыми данными и переходит к передаче.
Проще всего работу ARP иллюстрирует эта картинка:
Первый компьютер отправляет broadcast сообщение всем в широковещательном домене с запросом “У кого IP-адрес 10.10.10.2? Если у тебя, то сообщи свой MAC-адрес” и на что компьютер с этим адресом сообщает ему свой MAC.
Когда устройство назначения находится в удаленной сети, устройства третьего уровня одно за другим, повторяют тот же процесс, за исключением того, что отправляющее устройство отправляет ARP-запрос для MAC-адреса шлюза по умолчанию. После того, как адрес будет получен и шлюз по умолчанию получит пакет, шлюз по умолчанию передает IP-адрес получателя по связанным с ним сетям. Устройство уровня 3 в сети где находится устройство назначения использует ARP для получения MAC-адреса устройства назначения и доставки пакета.
Кэширование ARP
Поскольку сопоставление IP-адресов с MAC-адресами происходит на каждом хопе в сети для каждой дейтаграммы, отправленной в другую сеть, производительность сети может быть снижена. Чтобы свести к минимуму трансляции и ограничить расточительное использование сетевых ресурсов, было реализовано кэширование протокола ARP.
Кэширование ARP - это способ хранения IP-адресов и связанных c ними MAC-адресов данных в памяти в течение определенного периода времени, по мере изучения адресов. Это минимизирует использование ценных сетевых ресурсов для трансляции по одному и тому же адресу каждый раз, когда отправляются данные. Записи кэша должны поддерживаться, потому что информация может устаревать, поэтому очень важно, чтобы записи кэша устанавливались с истечением срока действия. Каждое устройство в сети обновляет свои таблицы по мере передачи адресов.
Статические и динамические записи в кеше ARP
Существуют записи статического ARP-кэша и записи динамического ARP-кэша. Статические записи настраиваются вручную и сохраняются в таблице кеша на постоянной основе. Статические записи лучше всего подходят для устройств, которым необходимо регулярно общаться с другими устройствами, обычно в одной и той же сети. Динамические записи хранятся в течение определенного периода времени, а затем удаляются.
Для статической маршрутизации администратор должен вручную вводить IP-адреса, маски подсети, шлюзы и соответствующие MAC-адреса для каждого интерфейса каждого устройства в таблицу. Статическая маршрутизация обеспечивает больший контроль, но для поддержания таблицы требуется больше работы. Таблица должна обновляться каждый раз, когда маршруты добавляются или изменяются.
Динамическая маршрутизация использует протоколы, которые позволяют устройствам в сети обмениваться информацией таблицы маршрутизации друг с другом. Таблица строится и изменяется автоматически. Никакие административные задачи не требуются, если не добавлен лимит времени, поэтому динамическая маршрутизация более эффективна, чем статическая маршрутизация.
Устройства, которые не используют ARP
Когда сеть делится на два сегмента, мост соединяет сегменты и фильтрует трафик на каждый сегмент на основе MAC-адресов. Мост создает свою собственную таблицу адресов, которая использует только MAC-адреса, в отличие от маршрутизатора, который имеет кэш ARP адресов, который содержит как IP-адреса, так и соответствующие MAC-адреса.
Пассивные хабы - это устройства центрального соединения, которые физически соединяют другие устройства в сети. Они отправляют сообщения всем портам на устройства и работают на уровне 1, но не поддерживают таблицу адресов.
Коммутаторы уровня 2 определяют, какой порт подключен к устройству, к которому адресовано сообщение, и отправлять сообщение только этому порту, в отличие от хаба, который отправляет сообщение всем его портам. Однако коммутаторы уровня 3 - это маршрутизаторы, которые создают кеш ARP (таблица).
Inverse ARP
Inverse ARP (InARP), который по умолчанию включен в сетях ATM, строит запись карты ATM и необходим для отправки одноадресных пакетов на сервер (или агент ретрансляции) на другом конце соединения. Обратный ARP поддерживается только для типа инкапсуляции aal5snap. Для многоточечных интерфейсов IP-адрес может быть получен с использованием других типов инкапсуляции, поскольку используются широковещательные пакеты.
Reverse ARP
Reverse ARP (RARP) - работает так же, как и протокол ARP, за исключением того, что пакет запроса RARP запрашивает IP-адрес вместо MAC-адреса. RARP часто используется бездисковыми рабочими станциями, потому что этот тип устройства не имеет способа хранить IP-адреса для использования при их загрузке. Единственный адрес, который известен - это MAC-адрес, поскольку он выжигается в сетевой карте. Для RARP требуется сервер RARP в том же сегменте сети, что и интерфейс устройства.
Proxy ARP
Прокси-ARP был реализован для включения устройств, которые разделены на физические сегменты сети, подключенные маршрутизатором в той же IP-сети или подсети для сопоставления адресов IP и MAC. Когда устройства не находятся в одной сети канала передачи данных (2-го уровня), но находятся в одной и той же IP-сети, они пытаются передавать данные друг другу, как если бы они находились в локальной сети. Однако маршрутизатор, который отделяет устройства, не будет отправлять широковещательное сообщение, поскольку маршрутизаторы не передают широковещательные сообщения аппаратного уровня. Поэтому адреса не могут быть сопоставлены.
Прокси-сервер ARP включен по умолчанию, поэтому «прокси-маршрутизатор», который находится между локальными сетями, отвечает своим MAC-адресом, как если бы это был маршрутизатор, к которому адресована широковещательная передача. Когда отправляющее устройство получает MAC-адрес прокси-маршрутизатора, он отправляет данные на прокси-маршрутизатор, который по очереди отправляет данные на указанное устройство.
Proxy ARP вызывается следующими условиями:
IP-адрес назначения не находится в той же физической сети (LAN), на которой получен запрос.
Сетевое устройство имеет один или несколько маршрутов к IP-адресу назначения.
Все маршруты к IP-адресу назначения проходят через интерфейсы, отличные от тех, на которых получен запрос.
Когда proxy ARP отключен, устройство отвечает на запросы ARP, полученные на его интерфейсе, только если IP-адрес назначения совпадает с его IP-адресом или если целевой IP-адрес в ARP-запросе имеет статически настроенный псевдоним ARP.
Serial Line Address Resolution Protocol
Serial Line ARP (SLARP) используется для последовательных интерфейсов, которые используют инкапсуляцию High Link Level Link Control (HDLC). В дополнение к TFTP-серверу может потребоваться сервер SLARP, промежуточное (промежуточное) устройство и другое устройство, предоставляющее услугу SLARP. Если интерфейс напрямую не подключен к серверу, промежуточное устройство требуется для пересылки запросов сопоставления адреса на сервер. В противном случае требуется напрямую подключенное устройство с сервисом SLARP.
Хотим рассказать про такой инструмент как Dialed Number Analyzer в Cisco Unified Communications Manager (CUCM) . Зачем он может понадобиться? Представьте, что вы настраиваете сложный dialplan на своем сервере, куда включены CSS, Partition, Route Group, Route Listb, Route Pattern и прочее. Как его протестировать и найти ошибки? Тут нам и понадобится Dialed Number Analyzer. Он позволит нам проанализировать созданный dialplan и предоставляет подробную информацию о потоке вызовов (callflow) набранных цифр.
/p>
Настройка
Прежде всего, нужно перейти в меню Cisco Unified Serviceability и перейти во вкладку Tools → Service Activation. Здесь нужно поставить галочку напротив строчки Cisco Dialed Number Analyzer, и нажать на Save.
После этого нужно перейти во вкладку Tools → Dialed Number Analyzer, либо по адресу https://[cm-machine]/dna. В открывшемся окне нажимаем Analysis → Analyzer.
Тут нам необходимо заполнить три обязательных поля:
Calling Party - Номер телефона, с которого будет идти тестовый звонок;
Dialed Digits – Набранные символы;
CSS - Calling Search Space для тестового телефона;
После нажатия кнопки Do Analysis мы увидим результат анализа, который покажет нам что произойдет со звонком, при заданных условиях.
Также можно делать отдельно анализ для шлюзов, телефонов и транков, выбрав в пункте Analysis вкладку Gateway, Phone или Trunk.