По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Сегодня мы обсудим разницу между технологией VPLS и MPLS, хотя оба эти метода используются для подключения клиентских сетей по всему миру. VPLS – сервисы виртуальной частной службы локальной сети и MPLS- мульти протокол с меткой переключения. VPLS vs. MPLS VPLS — это многоточечное подключение на основе технологии ETHERNET IP-сетей или оно может быть выполнено по сетям MPLS. VPLS — это один из способов подключения сетей, которые могут быть point to point или point to multipoint, или может быть тип подключения по IP-сетям multipoint to multipoint. Рис. 1 Базовая архитектура VPLS Если вы проанализируете подключение VPLS, то это подключение основано на технологии ETHERNET между сетями. Это означает, что подключение между сетями осуществляется на уровне L2. Все службы в VPLS, по-видимому, находятся в одном и том же сегменте локальной сети. VPLS использует пограничные маршрутизаторы, которые могут обучаться, соединяться и реплицироваться на основе VPN. Эти маршрутизаторы соединены полно связной сетью туннелей, что позволяет подключаться к любому каналу связи. С другой стороны, MPLS — это метод (это может быть L2 или L3) для подключения сетей по всему миру. В случае MPLS маршрутизация на границе (используемый протокол маршрутизации WAN-главным образом BGP, для подключения связи маршрутизатора PE-CE) и коммутация или маркировка используются в ядре. Таким образом, имеется в виду, что связь между PE-CE осуществляется через протокол маршрутизации (в случае, если используются сервисы MPLS L3), а PE-PE использует коммутацию меток внутри ядра (подключение MPLS L2 или L3). В случае услуг MPLS L2 технология, используемая между PE-CE, может быть Frame-Relay, ATM или любым другим соединением L2. Рис. 2 Подключение MPLS Таким образом, тег MPLS находится между L2 и L3 в модели OSI. Правильно говорят, что MPLS — это технология, а VPLS — это сервис, который использует технологию MPLS для подключения в качестве базовой службы. MPLS использует путевую карту и качество обслуживания с высокой доступностью. Краткое описание разницы: MPLS — это технология, в то время как VPLS — это сервис на вершине IP-сети или MPLS. VPLS — это соединение L2 между сетями, в то время как MPLS — это технология внутри поставщика услуг, и пользовательское соединение может быть L3 или L2 в зависимости от требования. VPLS использует интерфейсы ETHERNET для подключения между сетями, в то время как MPLS может быть запущен с любым типом интерфейсов С помощью MPLS вы можете иметь путевую карту и качество обслуживания, VPLS не может использовать путевую карту. VPLS обычно используется в промышленности, где клиент хочет, чтобы информация L2 передавалась по IP-сетям, в то время как MPLS может использоваться в обоих случаях, когда информация L2 или L3 может передаваться по сети MPLS. VPLS может быть point to point или multipoint соединением VPLS, в то время как MPLS является полностью сетчатой технологией и может использоваться для обмена информацией между сетями на основе требований заказчика (использование RT на месте для импорта и экспорта маршрутов с конкретными PE-маршрутизаторами) VPLS использует методы мостового соединения IEEE 802.1 q Ethernet, а ядро MPLS будет использовать полную сетку PW и переадресацию «split-horizon».
img
Если у тебя нет Winbox, или в целом ты «консольщик» - эта статья для тебя. Рассказываем, как обновить Mikrotik через консоль /p> Выбор канала Существует несколько каналов, через которые вы можете тянуть пакеты с обновлениями. Мы рекомендуем использовать текущую («current») ветку – она стабильна и надежна в работе. Если считаете так же, даем команду: system package update set channel=current Если вы рисковый парень, то можете использовать канал кандидатов на релиз («release candidate») :) Тут вы можете протестировать новые фичи, но лучше в «продакшн» системах его не использовать: system package update set channel=release-candidate Проверяем обновления Канал выбран. Проверяем, доступны ли для нас обновления: system package update check-for-updates Устанавливаем обновления Если новая более новая версия будет доступна, загружаем его: system package update download Новый пакет будет установлен после перезагрузки устройства (обновление произойдет на этапе загрузки Mikrotik). Финальный штрих – перезагрузка: system reboot
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. Прочитать полный код или попробовать плагины можно тут
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59