По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье вы узнаете о различных инструментах управления Kubernetes, которые можно использовать для управления кластерами Kubernetes.
В формирующейся облачной инфраструктуре Kubernetes повсюду, без сомнения, он стал стандартом для оркестрации контейнеров. Но обеспечение согласованной и безопасной работы нескольких кластеров Kubernetes, представляет собой новый набор проблем. Поэтому возникает потребность в инструментах управления Kubernetes.
Давайте рассмотрим некоторые популярные решения для эффективного управления Kubernetes.
Что такое DevOps, что нужно знать и сколько получают DevOps - специалисты?
1. K9s
k9s - панель мониторинга ресурсов на основе терминалов. Он имеет только интерфейс командной строки. Все что делали через веб-интерфейс панели мониторинга Kubernetes, вы можете сделать с помощью этой утилиты панели мониторинга терминала k9s.
Он постоянно следит за кластером Kubernetes и предлагает команды для работы с определенными ресурсами кластера.
Ниже приведены K9s функции:
Отслеживание состояния кластера в реальном времени
Настройка вида с помощью обложек K9s
Легкий переход между ресурсами Kubernetes
Параметры развертывания для проверки проблем с ресурсами кластера
Предоставляет расширенные подключаемые модули для создания собственных команд
2. Rancher
Rancher - платформа управления контейнерами с открытым исходным кодом, которая позволяет любому предприятию легко перенять Kubernetes. Вы можете развертывать и управлять облачными кластерами Kubernetes, работающими в GKE (GCP), EKS (AWS), AKS (Azure), или просто развертывать Kubernetes на виртуальных или физических машинах на ваш выбор.
Rancher упрощает все повседневные обязанности администратора, включая:
Мониторинг работоспособности кластеров
Настройка оповещений и уведомлений
Включение централизованного ведения журнала
Определение и применение глобальных политик безопасности
Установление аутентификации и применение наших политик обратной связи
Управление инфраструктурой и ее масштабирование
По мере ускорения внедрения Kubernetes в вашей компании, Кancher поощряет быстрое внедрение предоставления пользователям доступа непосредственно к Kubernetes API и CLI. Новый интеллектуальный интерфейс Rancher упрощает управление приложениями; команды могут легко развертывать рабочие нагрузки и управлять ими, определять объекты типа Секрет и управлять частными репозиториями, настраивать требования постоянных томов, настраивать балансировку нагрузки и обнаружение служб, управлять конвейерами CI.
3. Dashboard + Kubectl + Kubeadm
Панель управления Kubernetes представляет собой веб-интерфейс для развертывания контейнерных приложений. Он ищет и устраняет неисправности приложений и управляет кластером вместе с ресурсами.
С помощью панели мониторинга можно получить обзор приложений, запущенных в кластере, а также создать или изменить отдельные ресурсы Kubernetes, такие как задания развертывания, наборы реплик и многое другое.
Можно масштабировать развертывание или инициировать скользящее обновление, или даже перезапустить модуль или развернуть новые приложения с помощью мастера развертывания на панели мониторинга.
Kubectl - это средство командной строки для взаимодействия со службой API и отправки команд на главный узел. Его скрытые команды для вызовов API на сервер cluster API Kubernetes.
Kubeadm - это инструмент со встроенными командами для запуска минимального кластера Kubernetes. Он используется для начальной загрузки кластера, а не для подготовки компьютеров. С помощью kubeadm можно выполнить некоторые основные команды для загрузки кластера, создания маркера для присоединения к кластеру, возврата изменений, внесенных в кластер Kubernetes, и т.д.
4. Helm
Helm - менеджер пакетов для Kubernetes. Она позволяет разработчикам и операторам упаковывать, настраивать и развертывать приложения и службы в кластере Kubernetes. Он дает операторам больший контроль над кластерами Kubernetes, которые включают:
Упрощение, стандартизацию и многократное использование развертывания приложений
Простое описание сложных приложений с помощью диаграмм helm
Повышение производительности разработчиков
Снижение сложности развертывания
Повышает эксплуатационную готовность
Ускорение внедрения облачных приложений
Упрощает откат к предыдущей версии
Helm использует диаграммы, содержащие все определения ресурсов, для запуска приложений или служб в кластере Kubernetes. Здесь можно найти несколько helm диаграмм.
5. KubeSpray
KubeSpray - это диспетчер жизненного цикла кластера, который помогает развернуть готовый к эксплуатации кластер Kubernetes. Для автоматизации выделения ресурсов кластеров Kubernetes используется ansible-playbook.
Вот некоторые функции, которые включает в себя KubeSpray:
Основан на Ansible
Высокая доступность
Кроссплатформенность
Уровень производства
Возможность интеграции как с популярными поставщиками облачных инфраструктур, так и с железом
Различные опции конфигурации
Много платформенный CI/CD
Безопасность по умолчанию
По умолчанию Kubespray позволяет удаленно подключаться к кластеру Kubernetes через IP-адрес kube-master и порт 6443. Kubespray лучше всего подходит, если вам нужна гибкость в развертывании; он предоставляет множество пользовательских опций конфигурации.
Также, если вы знакомы с Ansible, то использование Kubespray вам покажется очень простым.
6. Kontena Lens
Kontena Lens - умная приборная панель для Kubernetes.
Это единственная система управления, которая вам понадобится, чтобы взять под контроль ваш Kubernetes. Он бесплатно доступен для операционных систем Mac OS, Windows и Linux. После запуска приложения Lens в интерфейсе появится список всех связанных кластеров.
Это самая мощная IDE для людей, которые действительно должны иметь дело с Kubernetes ежедневно. Вы можете обеспечить правильную настройку и настройку кластеров, а также более простую и быструю работу с кластерами и радикальное повышение производительности и скорости бизнеса.
Функции IDE Kontena Lens:
Возможность управления несколькими кластерами одновременно
Визуализация состояния кластера в реальном времени
Предоставляет встроенный терминал
Очень простая установка, поскольку это автономное приложение
Потрясающие возможности пользовательского интерфейса и пользователя
Поддерживается Kubernetes RBAC.
Протестировано для обработки почти 25K модулей в кластере
Kubernetes - это сложный инструмент, и Lens IDE помогает даже новичкам легко начать работу с Kubernetes. Это один из лучших инструментов для управления и визуализации кластеров Kubernetes.
7. WKSctl
WKSctl обозначает управление системой Weave Kubernetes. Является частью Wave Kubernetes Platform.
WKSctl - это инструмент, использующий GitOps для управления конфигурацией Kubernetes. GitOps - это не что иное, как набор практик, которые используют запросы git для управления приложениями и инфраструктурой традиционным способом.
С помощью WKSctl можно управлять кластерами Kubernetes через Git commits. Можно обновить кластер, добавлять или удалять узлы из кластера.
Этот инструмент можно запускать в 2 режимах: автономном и режиме GitOps. В автономном режиме создается статический кластер. В режиме GitOps он настраивает кластер в соответствии с данными cluster.yml и machines.yml, имеющимися в git.
Функции WKSctl:
Быстрый запуск кластера с git
Откат в случае сбоя развертывания
Регистрация изменения для рассмотрения и аудита
Для создания кластера требуются только IP-адрес и ключи ssh
Непрерывная проверка и корректировка состояние кластера
Заключение
Это был краткий обзор популярных инструментов управления Kubernetes кластерами. Выберите любой из вышеупомянутых инструментов и опробуйте его на своем кластере Kubernetes!
В статье мы попытаемся разобраться в том, что такое Ephone и Ephone-DN в CME (CUCME) , в чем их отличие и как с ними работать. Если описать все в двух словах, то для CME Ephone это телефонный аппарат, а Ephone-DN это телефонный номер. А теперь рассмотрим это подробнее.
Настройка Ephone-DN
Ephone-DN в простом представлении это телефонный номер (Directory Number), который может быть назначен на одну или несколько кнопок IP телефона Cisco. Каждый созданный ephone-dn можно настроить в режиме single-line или dual-line. Вот в чем разница:
Single-line ephone-dn: в этом режиме ephone-dn может одновременно посылать и принимать только один вызов. Если звонок приходит на ephone-dn, который уже учавствует в разговоре, то вызывающий абонент услышит сигнал “занято”
Dual-line ephone-dn: в этом режиме телефон может управиться с двумя одновременными вызовами. Это полезно для функций консультативного трансфера, конференций и функции ожидания вызова.
Обычно dual-line используется для IP-телефонов пользователей, а single-line для сетевых функций, таких как интерком или пейджинг.
Рассмотрим конфигурацию этих двух вариантов:
CME#conf t – вход в режим конфигурации
CME(config)#ephone-dn 1 – создание ephone-dn c меткой 1 (метка используется при привязке к ephone, ограничивается параметром max-dn)
CME(config-ephone-dn)# number 1000 – указание номера (до 16 цифр)
CME(config-ephone-dn)#exit – выход в предыдущее меню
CME(config)#ephone-dn 2 dual-line – создание ephone-dn в режиме dual-line
CME(config-ephone-dn)#number 1001 – указание номера
Новые версии IOS поддерживают конфигурацию octo-line, которая включает поддержку восьми звонков на линии. Такая конфигурация можно использоваться для телефонов на ресепшене, shared lines (когда много людей используют один и тот же номер) или как ресурс конференции.
Также при создании ephone-dn можно указать дополнительный номер, используя команду secondary, например для приема вызовов с ТфОП используя DID(Direct Inward Dial) .
CME(config)#ephone-dn 2 dual-line
CME(config-ephone-dn)#number 1001 secondary 849964919131001
Настройка Ephone
Ephone представляет собой конфигурацию, которая применяется к определенному IP-телефону Cisco или софтфону. Для добавления телефона необходимо ввести команду ephone, затем метку (метка ограничивается параметром max-ephones), после чего мы провалимся в раздел конфигурации ephone, где нужно логически связать ephone-dn с физическим IP телефоном, который он представляет. Для этого используется MAC-адрес телефона Cisco, узнать можно который тремя способами: он написан на коробке из под телефона, он написан на задней панели самого телефона и его можно найти в настройках самого телефона в меню настроек.
Рассмотрим пример:
CME(config)#ephone 1 – создание ephone с меткой 1
CME(config)#mac-address 0014.1c48.12ab – MAC-адрес телефона, с которым будет связан ephone 1
Связывание Ephone и Ephone-dn
Теперь можно связать созданные Ephone и Ephone-dn, и делается это при помощи присваивания ephone-dn к физической кнопке телефона ephone .
Синтаксис команды следующий: button [физическая кнопка] [разделитель] [метка ephone-dn]
Например, рассмотрим пример, в котором мы присваиваем ephone-dn 2 на первую клавишу на телефоне ephone 1:
CME(config)#ephone 1 – вход в меню настройки ephone
CME(config-ephone)#button 1:2 – сопоставление ephone-dn с клавишей
CME(config-ephone)#restart – перезагружает телефон, после чего он перекачивает конфигурационный файл с tftp сервера.
Разделитель в виде двоеточия обозначает, что это будет обычный звонок.
Существует несколько видов разделителей:
: - обычный звонок, визуальная индикация включена
b – звуковой сигнал (beep). Визуальная индикация на телефоне такая же, как и при обычном звонке
f – функциональный звонок. Тип звонка отличается при внутренних и внешних вызовах
m – режим мониторинга на общей линии (shared line). Индикатор состояния линии показывает, используется ли линия. Может использоваться как быстрый набор для просматриваемой линии. Отсутствует возможность принимать звонки.
w – режим просмотра для всех линий, у которых этот номер является основным
s – тихий звонок, подавляет звуковые сигналы и звук ожидания вызова для этой линии. Визуальная индикация такая же, как и при обычном звонке.
Выглядеть это будет так:
На телефон можно назначить несколько линий, путем ввода нескольких команд button в режиме конфигурации ephone.
Для проверки можно использовать команду show ephone:
CME# show ephone
ephone-1 Mac:0014.1c48:12ab TCP socket: [5] activeLine:0 REGISTERED in SCCP ver 8 and Server in ver 8
mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 caps:7
IP: 192.168.1.6 14719 7912 keepalive 2702 max_line 2 dual-line
button 1: dn 2 number 1001 CH1 IDLE CH2 IDLE
button 2: dn 1 number 1000 CH1 IDLE
Буферизация пакетов для работы с перегруженным интерфейсом кажется прекрасной идеей. Действительно, буферы необходимы для обработки трафика, поступающего слишком быстро или несоответствия скорости интерфейса - например, при переходе от высокоскоростной LAN к низкоскоростной WAN. До сих пор это обсуждение QoS было сосредоточено на классификации, приоритизации и последующей пересылке пакетов, помещенных в очередь в этих буферах, в соответствии с политикой. Максимально большой размер буферов кажется хорошей идеей. Теоретически, если размер буфера достаточно велик, чтобы поставить в очередь пакеты, превышающие размер канала, все пакеты в конечном итоге будут доставлены. Однако, как большие, так и переполненные буферы создают проблемы, требующие решения.
Когда пакеты находятся в буфере, они задерживаются. Некоторое количество микросекунд или даже миллисекунд добавляется к пути пакета между источником и местом назначения, пока они находятся в буфере, ожидая доставки. Задержка перемещения является проблемой для некоторых сетевых разговоров, поскольку алгоритмы, используемые TCP, предполагают предсказуемую и в идеале небольшую задержку между отправителем и получателем.
В разделе активного управления очередью вы найдете различные методы управления содержимым очереди. Некоторые методы решают проблему переполненной очереди, отбрасывая достаточно пакетов, чтобы оставить немного места для вновь поступающих. Другие методы решают проблему задержки, поддерживая небольшую очередь, минимизируя время, которое пакет проводит в буфере. Это сохраняет разумную задержку буферизации, позволяя TCP регулировать скорость трафика до скорости, соответствующей перегруженному интерфейсу.
Управление переполненным буфером: взвешенное произвольное раннее обнаружение (WRED)
Произвольное раннее обнаружение (RED) помогает нам справиться с проблемой переполненной очереди. Буферы не бесконечны по размеру: каждому из них выделено определенное количество памяти. Когда буфер заполняется пакетами, новые поступления отбрасываются. Это не сулит ничего хорошего для критического трафика, такого как VoIP, от которого нельзя отказаться, не повлияв на взаимодействие с пользователем. Способ решения этой проблемы - убедиться, что буфер никогда не будет полностью заполнен. Если буфер никогда не заполняется полностью, то всегда есть место для приема дополнительного трафика.
Чтобы предотвратить переполнение буфера, RED использует схему упреждающего отбрасывания выбранного входящего трафика, оставляя места открытыми. Чем больше заполняется буфер, тем больше вероятность того, что входящий пакет будет отброшен. RED является предшественником современных вариантов, таких как взвешенное произвольное раннее обнаружение (WRED). WRED учитывает приоритет входящего трафика на основе своей отметки. Трафик с более высоким приоритетом будет потерян с меньшей вероятностью. Более вероятно, что трафик с более низким приоритетом будет отброшен. Если трафик использует какую-либо форму оконного транспорта, например, такую как TCP, то эти отбрасывания будут интерпретироваться как перегрузка, сигнализирующая передатчику о замедлении.
RED и другие варианты также решают проблему синхронизации TCP. Без RED все входящие хвостовые пакеты отбрасываются при наличии переполненного буфера. Для трафика TCP потеря пакетов в результате отбрасывания хвоста приводит к снижению скорости передачи и повторной передаче потерянных пакетов. Как только пакеты будут доставлены снова, TCP попытается вернуться к более высокой скорости. Если этот цикл происходит одновременно во многих разных разговорах, как это происходит в сценарии с отключением RED-free, интерфейс может испытывать колебания использования полосы пропускания, когда канал переходит от перегруженного (и сбрасывания хвоста) к незагруженному и недоиспользованному, поскольку все д throttled-back TCP разговоры начинают ускоряться. Когда уже синхронизированные TCP-разговоры снова работают достаточно быстро, канал снова становится перегруженным, и цикл повторяется.
RED решает проблему синхронизации TCP, используя случайность при выборе пакетов для отбрасывания. Не все TCP-разговоры будут иметь отброшенные пакеты. Только определенные разговоры будут иметь отброшенные пакеты, случайно выбранные RED. TCP-разговоры, проходящие через перегруженную линию связи, никогда не синхронизируются, и колебания избегаются. Использование каналов связи более устойчиво.
Управление задержкой буфера, Bufferbloat и CoDel
Здесь может возникнуть очевидный вопрос. Если потеря пакетов - это плохо, почему бы не сделать буферы достаточно большими, чтобы справиться с перегрузкой? Если буферы больше, можно поставить в очередь больше пакетов, и, возможно, можно избежать этой досадной проблемы потери пакетов. Фактически, эта стратегия больших буферов нашла свое применение в различных сетевых устройствах и некоторых схемах проектирования сети. Однако, когда перегрузка канала приводит к тому, что буферы заполняются и остаются заполненными, большой буфер считается раздутым. Этот феномен так хорошо известен в сетевой индустрии, что получил название: bufferbloat.
Bufferbloat имеет негативный оттенок, потому что это пример слишком большого количества хорошего. Буферы - это хорошо. Буферы предоставляют некоторую свободу действий, чтобы дать пачке пакетов где-нибудь остаться, пока выходной интерфейс обработает их. Для обработки небольших пакетов трафика необходимы буферы с критическим компромиссом в виде введения задержки, однако превышение размера буферов не компенсирует уменьшение размера канала. Канал имеет определенную пропускную способность. Если каналу постоянно предлагается передать больше данных, чем он может передать, то он плохо подходит для выполнения требуемой от него задачи. Никакая буферизация не может решить фундаментальную проблему пропускной способности сети.
Увеличение размера буфера не улучшает пропускную способность канала. Фактически, постоянно заполненный буфер создает еще большую нагрузку на перегруженный интерфейс. Рассмотрим несколько примеров, противопоставляющих протоколов Unacknowledged Datagram Protocol (UDP) и Transmission Control Protocol (TCP).
В случае VoIP-трафика буферизованные пакеты прибывают с опозданием. Задержка чрезвычайно мешает голосовой беседе в реальном времени. VoIP - это пример трафика, передаваемого посредством UDP через IP. UDP-трафик не подтверждается. Отправитель отправляет пакеты UDP, не беспокоясь о том, доберутся ли они до места назначения или нет. Повторная передача пакетов не производится, если хост назначения не получает пакет UDP. В случае с VoIP - здесь важно, пакет приходит вовремя или нет. Если это не так, то нет смысла передавать его повторно, потому что уже слишком поздно. Слушатели уже ушли. LLQ может прийти вам в голову как ответ на эту проблему, но часть проблемы - это слишком большой буфер. Для обслуживания большого буфера потребуется время, вызывающее задержку доставки трафика VoIP, даже если LLQ обслуживает трафик VoIP. Было бы лучше отбросить VoIP-трафик, находящийся в очереди слишком долго, чем отправлять его с задержкой.
В случае большинства приложений трафик передается по протоколу TCP через IP, а не по протоколу UDP. TCP - протокол подтверждений. Отправитель трафика TCP ожидает, пока получатель подтвердит получение, прежде чем будет отправлен дополнительный трафик. В ситуации bufferbloat пакет находится в переполненном, слишком большом буфере перегруженного интерфейса в течение длительного времени, задерживая доставку пакета получателю. Получатель получает пакет и отправляет подтверждение. Подтверждение пришло к отправителю с большой задержкой, но все же пришло. TCP не заботится о том, сколько времени требуется для получения пакета, пока он туда попадает. И, таким образом, отправитель продолжает отправлять трафик с той же скоростью через перегруженный интерфейс, что сохраняет избыточный буфер заполненным и время задержки увеличивается. В крайних случаях отправитель может даже повторно передать пакет, пока исходный пакет все еще находится в буфере. Перегруженный интерфейс, наконец, отправляет исходный буферизованный пакет получателю, а вторая копия того же пакета теперь находится в движении, что создает еще большую нагрузку на уже перегруженный интерфейс!
Эти примеры демонстрируют, что буферы неподходящего размера на самом деле не годятся. Размер буфера должен соответствовать как скорости интерфейса, который он обслуживает, так и характеру трафика приложения, который может проходить через него.
Одна из попыток со стороны сетевой индустрии справиться с большими буферами, обнаруженными вдоль определенных сетевых путей, - это контролируемая задержка, или CoDel. CoDel предполагает наличие большого буфера, но управляет задержкой пакетов, отслеживая, как долго пакет находится в очереди. Это время известно, как время пребывания. Когда время пребывания пакета превысило вычисленный идеал, пакет отбрасывается. Это означает, что пакеты в начале очереди-те, которые ждали дольше всего-будут отброшены до пакетов, находящихся в данный момент в хвосте очереди.
Агрессивная позиция CoDel в отношении отбрасывания пакетов позволяет механизмам управления потоком TCP работать должным образом. Пакеты, доставляемые с большой задержкой, не доставляются, а отбрасываются до того, как задержка станет слишком большой. Отбрасывание вынуждает отправителя TCP повторно передать пакет и замедлить передачу, что очень желательно для перегруженного интерфейса. Совокупный результат - более равномерное распределение пропускной способности для потоков трафика, конкурирующих за интерфейс.
В ранних реализациях CoDel поставлялся в устройства потребительского уровня без параметров. Предполагаются определенные настройки по умолчанию для Интернета. Они включают 100 мс или меньше времени двустороннего обмена между отправителями и получателями, а задержка 5 мс является максимально допустимой для буферизованного пакета. Такая конфигурация без параметров упрощает деятельность поставщиков сетевого оборудования потребительского уровня. Потребительские сети являются важной целью для CoDel, поскольку несоответствие высокоскоростных домашних сетей и низкоскоростных широкополосных сетей вызывает естественную точку перегрузки. Кроме того, сетевое оборудование потребительского уровня часто страдает от слишком большого размера буферов.