По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Сегодня в статье рассказываем про плагин kubectl, который использует tmux, чтобы быстрее устранить неполадки Kubernetes. Kubernetes - это процветающая платформа для взаимодействия контейнеров с открытым исходным кодом, которая обеспечивает масштабируемость, высокую доступность, надежность и отказоустойчивость приложений. Одной из его многочисленных функций является поддержка запуска пользовательских сценариев или двоичных файлов через основной двоичный файл клиента, kubectl. Kubectl очень мощный, и позволяет пользователям делать с ним все, что они могли бы сделать непосредственно в кластере Kubernetes. Устранение неполадок с псевдонимами Kubernetes Каждый, кто использует Kubernetes для управления контейнерами, знает о его особенностях - а также о сложности, причиной которого является его дизайн. Например, существует острая необходимость упростить поиск и устранение неисправностей в Kubernetes с помощью чего-то более быстрого и практически не требующего ручного вмешательства (за исключением критических ситуаций). Существует много сценариев, которые следует учитывать при устранении неполадок. В одном сценарии вы знаете, что нужно запускать, но синтаксис команды - даже если она может выполняться как одна команда - чрезмерно сложен, или для работы может потребоваться один-два входа. Например, если часто требуется перейти в запущенный контейнер в пространстве имен System, вы можете неоднократно писать: kubectl --namespace=kube-system exec -i -t <your-pod-name> Для упрощения поиска и устранения неисправностей можно использовать псевдонимы этих команд в командной строке. Например, можно добавить следующие файлы dotfiles (.bashrc или .zshrc): alias ksysex='kubectl --namespace=kube-system exec -i -t' Это один из многих примеров из хранилища общих псевдонимов Kubernetes, который показывает один из способов упрощения функций в kubectl. Для чего-то простого, подобного этому сценарию, достаточно псевдонима. Переключение на подключаемый модуль kubectl Более сложный сценарий устранения неполадок включает в себя выполнение множества команд, одной за другой, для исследования среды и выведения заключения. Одних псевдонимов недостаточно для этого варианта использования; необходима воспроизведение логического узла и корреляция между многими частями развертывания Kubernetes. На самом деле вам нужна автоматизация для получения нужного результата за меньшее время. Рассмотрим пространства имен от 10 до 20 или даже от 50 до 100, содержащие различные микросервисы в вашем кластере. Что поможет вам начать устранение неполадок в этом сценарии? Вам потребуется что-то, что может быстро определить, какой модуль в каком пространстве имен вызывает ошибки. Вам понадобится что-то, что сможет просматривать журналы всех модулей в пространстве имен. Также может потребоваться просмотр журналов определенных модулей в определенном пространстве имен, в котором были обнаружены ошибки. Любое решение, охватывающее эти вопросы, было бы очень полезно при изучении производственных проблем, а также в ходе циклов разработки и тестирования. Чтобы создать нечто более мощное, чем простой псевдоним, можно использовать плагины kubectl. Плагины подобны автономным сценариям, написанным на любом языке сценариев, но предназначены для расширения функциональных возможностей главной команды при работе в качестве администратора Kubernetes. Чтобы создать плагин, необходимо использовать правильный синтаксис kubectl- < имя-плагина > для того, чтобы скопировать сценарий в один из экспортированных путей в $PATH и предоставить ему исполняемые разрешения chmod+x. После создания плагина и перемещения его в свой путь, вы можете немедленно запустить его. Например, у меня на пути есть kubectl-krwl и kubectl-kmux: $ kubectl plugin list The following compatible plugins are available: /usr/local/bin/kubectl-krawl /usr/local/bin/kubectl-kmux $ kubectl kmux Теперь давайте изучим, как выглядит обеспечение работы Kubernetes с tmux. Использование силы tmux Tmux - очень мощный инструмент, на который полагаются многие команды для устранения проблем, связанных с упрощением работы - от разделения окон на панели для выполнения параллельной отладки на нескольких машинах до мониторинга журналов. Одним из основных его преимуществ является то, что его можно использовать в командной строке или в сценариях автоматизации. Я создал плагин kubectl, который использует tmux, чтобы сделать поиск и устранение неисправностей гораздо проще. Я буду использовать аннотации, чтобы пройти через логику за плагином (и оставить его для вас, чтобы пройти через полный код плагина): #NAMESPACE is namespace to monitor. #POD is pod name #Containers is container names # initialize a counter n to count the number of loop counts, later be used by tmux to split panes. n=0; # start a loop on a list of pod and containers while IFS=' ' read -r POD CONTAINERS do # tmux create the new window for each pod tmux neww $COMMAND -n $POD 2>/dev/null # start a loop for all containers inside a running pod for CONTAINER in ${CONTAINERS//,/ } do if [ x$POD = x -o x$CONTAINER = x ]; then # if any of the values is null, exit. warn "Looks like there is a problem getting pods data." break fi # set the command to execute COMMAND=”kubectl logs -f $POD -c $CONTAINER -n $NAMESPACE” # check tmux session if tmux has-session -t <session name> 2>/dev/null; then <set session exists> else <create session> fi # split planes in the current window for each containers tmux selectp -t $n ; splitw $COMMAND ; select-layout tiled ; # end loop for containers done # rename the window to identify by pod name tmux renamew $POD 2>/dev/null # increment the counter ((n+=1)) # end loop for pods done< <(<fetch list of pod and containers from kubernetes cluster>) # finally select the window and attach session tmux selectw -t <session name>:1 ; attach-session -t <session name>; После запуска скрипта плагина он будет выдавать выходные данные, аналогичные изображению ниже. Каждый модуль имеет собственное окно, и каждый контейнер (если их несколько) разделяется панелями в окне модуля в потоковые журналы по мере их поступления. Преимущество tmux можно увидеть ниже; При правильной конфигурации можно даже увидеть, какое окно активно (см. белые вкладки). Заключение Псевдонимы всегда полезны для простого устранения неполадок в средах Kubernetes. Когда среда становится более сложной, плагин kubectl является мощным вариантом для использования более продвинутых сценариев. Ограничения в выборе языка программирования, который можно использовать для записи плагинов kubectl, нет. Единственное требование состоит в том, чтобы соглашение об именовании в пути являлось исполняемым и не имело того же имени, что и существующая команда kubectl. Прочитать полный код или попробовать плагины можно тут
img
Всем привет! В этой статье мы расскажем о том, что такое Device Pool в Cisco Unified Communications Manager (CUCM) и как его настроить. Device Pool можно представить как набор конфигураций и шаблонов, который применяется к группе устройств. Их можно создавать сколько угодно и использовать для разных локаций или функций абонентов (например, отдельные Device Pool’ы для центрально офиса и филиалов в другом городе). Но прежде чем создавать Device Pool необходимо настроить несколько разделов, которые будут использоваться в Device Pool’е Cisco Unified CM Group Эта группа определяет, на каких серверах и в каком порядке должна происходить регистрация телефона. Первый в списке сервер является основным, остальные являются дополнительными и телефоны регистрируются на них, если у них не получилось зарегистрироваться на основном. Для добавления Cisco Unified CM группы нужно перейти во вкладку System → Cisco Unified CM Group и нажать Add New. В появившемся меню в поле Name указываем название группы, а ниже в поле Selected Cisco Unified Communications Managers добавляем наши серверы в желаемом порядке (доступные серверы находятся в поле Available Cisco Unified Communications Managers). Изменить приоритет можно кнопкой со стрелкой. Region Разделение на регионы нужно для определения пропускной способности аудио и видео звонков внутри и между регионами. Аудио кодек определяет тип сжатия и максимум использования полосы пропускания, которая используется при звонке. Для создания региона нужно перейти во вкладку System → Region и нажимаем на кнопку Add New Region. Далее указываем имя региона и попадаем на страницу настроек. В поле Regions выбираем, с каким регионом мы хотим настроить связь (если хотим применить настройки внутри региона то выбиваем в этом поле его самого), из выпадающего списка Audio Codec выбираем желаемый кодек, в поле Video Call Bandwidth указываем пропускную способность для видеозвонков и далее выбираем Link-Loss Type на случай потерь. После чего нажимаем Save и настройки пропускной способности между регионами переносятся в верхнюю часть в поле Region Relationships. Date/Time Group Использование Date/Time групп нужно для определения временных зон аппаратов, подключенных к CUCM. При установке CUCM автоматически создается группа CMLocal, дата и время которой синхронизированы с ОС системы, на которой установлен CUCM. Для создания новой группы переходим во вкладку System → Date/Time Group и нажимаем Add New Date/Time Group. В новом окне указываем ее название в поле Group Name, в поле Time Zone выбираем временную зону, разделитель выбираем в поле Separator, форматы даты и времени выбираем в полях Date Format и Time Format. Создание Device Pool Переходим во вкладку System → Device Pool и нажимаем Add New. Тут четыре поля обязательны к заполнению. Первое это название Device Pool’а, а остальные ты мы настроили ранее - это Cisco Unified Communications Manager Group, Region и Date/Time Format. Остальные поля можно заполнить, выбрав пункт по умолчанию. После заполнения всех полей нажимаем Save и сохраняем наш Device Pool. Теперь его можно применить в настройках уже созданного телефона, либо выбирать его при создании нового.
img
В статье мы покажем, как использовать команды маршрутизации в Linux (в UNIX подобных системах) чтобы отображать или конфигурить информацию о дефолтных маршрутах. Погнали разбираться! Показать маршруты по умолчанию Ловите 2 команды, которые помогут отобразить текущую таблицу маршрутизации в Linux: # route Вывод такой команды будет примерно следующим: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 ra0 default dsl-router 0.0.0.0 UG 0 0 0 ra0 Или можно использовать второй вариант: $ /sbin/route ”Выхлоп” такой команды в той же самой таблице маршрутизации: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 191.255.255.0 * 255.255.255.0 U 0 0 0 eth0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth0 default 191.255.255.1 0.0.0.0 UG 0 0 0 eth0 Настройка дефолтного маршрута Синтаксис настройки категорически прост. Смотрите: route add default gw {IP-АДРЕС} {ИНТЕРФЕЙС} Тут: IP-АДРЕС - IP - адрес шлюза; ИНТЕРФЕЙС - имя интерфейса, за которым сидит указанный выше шлюз; Например, если IP - адрес вашего роутера 192.168.1.254 и он сидит на интерфейсом eth0, то из под root выполните команду: # route add default gw 192.168.1.254 eth0 Или можно использовать хостнейм (только проверьте, чтобы он резолвился на уровне DNS): # route add default gw dsl-router eth0 Или можно использовать команду ip, чтобы маршрутизировать весь трафик через шлюз 192.168.1.254, который подключен к интерфейсу eth0: # ip route add 192.168.1.0/24 dev eth0 Либо вместо eth0 интерфейса можно прописать в явном виде адрес шлюза. Тут ап ту ю, как говорится :) # ip route add 192.168.1.0/24 via 192.168.1.254 Профит!
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59