По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Helm — это инструмент развертывания Kubernetes для автоматизации создания, упаковки, настройки и развертывания приложений и служб в кластерах Kubernetes.
Kubernetes — это мощная система управления контейнеризацией для развертывания приложений. Для этого существует несколько независимых ресурсов, и для каждого требуется отдельный YAML-файл манифеста.
В этой статье расскажем, что такое Helm и Helm Charts, а также как автоматизировать развертывание приложений в Kubernetes.
Что такое Helm?
Если бы Kubernetes был операционной системой, то Helm был бы менеджером пакетов. Ubuntu использует apt, CentOS использует yum, а Kubernetes использует helm.
Helm развертывает пакетные приложения в Kubernetes и структурирует их в чарты (Helm Charts). Чарты содержат все предустановленные ресурсы приложения вместе со всеми версиями, которые помещены в один легко управляемый пакет.
Helm упрощает установку, обновление, вызов зависимостей и настройку развертываний в Kubernetes с помощью простых CLI-команд. Пакеты программного обеспечения находятся в репозиториях или создаются.
Почему нам нужен Helm?
Объектами Kubernetes сложно управлять. Благодаря полезным инструментам освоение Kubernetes становится плавным и удобным. Helm автоматизирует обслуживание YAML-файлов для объектов Kubernetes, упаковывая информацию в чарты и анонсируя их в кластере Kubernetes.
Helm отслеживает историю версий для каждой установки и изменения чарта. Откат к предыдущей версии или обновление до более новой выполняется понятными командами.
Доступные команды:
Completion — создает сценарий автозаполнения для указанной оболочки.
Create — создает новый чарт с заданным именем.
Dependency — управление зависимостями чарта.
Env — информация о клиентской среде Helm.
Get — загрузка расширенной информации об именованном релизе.
Help — помощь по любой команде.
History — получить историю релизов.
Install — установить чарт.
Lint — проверить чарт на возможные проблемы.
List — список релизов.
Package — упаковать каталог чарта в архив чарта.
Plugin — установить, внести в список или удалить плагины Helm.
Pull — загрузить чарт из репозитория или (опционально) распаковать его в локальный каталог.
Repo — установка, внесение в список, удаление, обновление и индексация репозиториев чартов.
Rollback — откат релиза к предыдущей версии.
Search — поиск в чарте по ключевым словам.
Show — показать информацию о чарте.
Status — отображение статуса названного релиза.
Template — локальное отображение шаблонов.
Test — запустить тесты релиза.
Uninstall — деинсталлировать релиз.
Upgrade — обновить релиз.
Verify — проверить, что чарт по указанному пути подписан и действителен.
Version — распечатать информацию о версии клиента.
Что вы можете сделать с помощью Helm?
Helm позволяет разработчикам программного обеспечения развертывать и тестировать среду самым простым способом. Требуется меньше времени, чтобы перейти от разработки к тестированию и продакшену.
Помимо повышения производительности, Helm предоставляет разработчикам удобный способ упаковки и отправки приложений конечным пользователям для установки.
Как работает Helm?
Helm и Kubernetes работают как клиент-серверное приложение. Клиент Helm отправляет ресурсы в кластер Kubernetes. Серверная часть зависит от версии: Helm 2 использует Tiller, тогда как Helm 3 избавился от Tiller и полностью полагается на Kubernetes API.
Что такое Helm Charts?
Чарты Helm (Helm Charts) — это пакеты Helm, состоящие из файлов и шаблонов YAML, которые преобразуются в файлы манифеста Kubernetes. Чарты могут повторно использоваться кем угодно и в любой среде, что уменьшает сложность и количество дубликатов. Папки имеют следующую структуру:
Как работают чарты Helm?
Три основные концепции чартов Helm:
Чарт — предварительно настроенный шаблон ресурсов Kubernetes.
Релиз — чарт, развернутый с помощью Helm в кластере Kubernetes.
Репозиторий — общедоступные чарты.
Рабочий процесс заключается в поиске чартов через репозитории и создании релизов путем установки чартов в кластеры Kubernetes.
Структура чарта Helm
Файлы и каталоги чарта Helm имеют определенную функцию:
Название
Тип
Функция
charts/
Каталог
Каталог для управляемых вручную зависимостей чарта.
templates/
Каталог
Написанные на языке Go файлы шаблонов, объединенные с конфигурационными значениями из файла values.yaml и предназначенные для генерации манифестов Kubernetes.
Chart.yaml
Файл
Метаданные о чартах, такие как: версия, имя, ключевые слова для поиска и так далее.
LICENSE (опционально)
Файл
Лицензия на чарт в текстовом формате.
README.md (опционально)
Файл
Удобочитаемая информация для пользователей чарта.
requirements.yaml (опционально)
Файл
Список зависимостей чарта.
values.yaml
Файл
Настройки чарта по умолчанию.
Создавайте чарты Helm вручную или собирайте общедоступные чарты из репозиториев.
Репозитории чартов Helm
Репозитории содержат чарты, которые могут быть установлены или предоставлены для доступа другим пользователям. Helm обеспечивает поиск напрямую из клиента. Существует два основных типа поиска:
helm search hub — поиск через Artifact Hub из множества репозиториев.
helm search repo — поиск через репозитории, добавленные в локальном клиенте Helm с помощью helm repo add.
Без каких-либо фильтров в результатах поиска отображаются все доступные чарты. Чтобы уточнить запрос, добавьте условие поиска. Например:
helm search hub wordpress
Когда найдете подходящий чарт, установите его с помощью helm install.
Релизы чартов
При установке чарта создается новый пакет. Команда helm install принимает два аргумента:
helm install <release name> <chart name>
Запуск helm install выводит полезную информацию и указывает, следует ли вам предпринять какие-либо действия для установки. Чарты кастомизируемы и легко настраиваются перед установкой. Релизы Helm легко поддерживать и откатывать в случае любых нежелательных изменений.
Почитатей первую часть статьи про траблшутинг NAT/PAT на Cisco.
В этой части мы рассмотрим проблемы DHCP.
Урок 1
Вот новый сценарий, позвольте мне сначала объяснить его:
Зеленая зона - это наша локальная сеть, так что это наш NAT inside.
Красная область - это Интернет, поэтому это наш NAT outside.
Предполагается, что хост - это компьютер с шлюзом по умолчанию 192.168.12.2.
Наш маршрутизатор NAT подключен к маршрутизатору ISP.
Маршрутизатор ISP назначил нам подсеть 172.16.1.0 / 24, которую мы собираемся использовать для трансляции NAT.
BGP был настроен между NAT и маршрутизатором ISP для доступа к сети 192.168.34.0/24.
Предполагается, что веб-сервер прослушивает TCP-порт 80 и использует 192.168.34.3 в качестве шлюза по умолчанию.
Однако пользователи нашей локальной сети жалуются на то, что не могут подключиться к веб-серверу. Давайте проверим нашу конфигурацию NAT:
Мы можем убедиться, что трансляция работает:
Inside local IP-адрес нашего хоста.
Inside global находится один из IP-адресов из нашей подсети 172.16.1.0/24.
Outside local and global IP-адрес нашего веб-сервера
Эта трансляция выглядит хорошо, потому что все IP-адреса верные.
Мы видим, что маршрутизатор NAT научился достигать сети 192.168.34.0 / 24 через BGP.
Наш NAT-маршрутизатор может подключаться к веб-серверу, поэтому проблема с подключением отсутствует. Однако следует помнить одну важную вещь. Пакет IP, который производит маршрутизатор NAT, выглядит следующим образом:
IP-адрес получателя является нашим веб-сервером, и с ним нет проблем. Исходный IP-адрес - 192.168.23.2, и поскольку мы получили ответ, мы знаем, что маршрутизатор ISP знает, как достичь подсети 192.168.23.0 / 24. Это важно, поскольку подсеть 192.168.23.0 / 24 напрямую подключена к маршрутизатору ISP.
Однако, если мы отправляем эхо-запрос с хост-устройства, он преобразуется из-за NAT в IP-адрес в подсети 172.16.1.0/24. Пакет IP будет выглядеть так:
Вот что происходит, когда этот IP-пакет покидает маршрутизатор NAT и отправляется маршрутизатору ISP:
Маршрутизатор ISP получает IP-пакет и проверяет свою таблицу маршрутизации, знает ли он, куда отправлять трафик для сети 192.168.34.0 / 24.
Сеть 192.168.34.0/24 напрямую подключена к маршрутизатору ISP, поэтому она выполняет запрос ARP для MAC-адреса веб-сервера, получает ответ ARP и может пересылать IP-пакет на веб-сервер.
Веб-сервер хочет ответить, и он создает новый IP-пакет с IP-адресом назначения 172.16.1.
Поскольку веб-сервер имеет маршрутизатор ISP в качестве шлюза по умолчанию, он отправит IP-пакет маршрутизатору ISP.
Маршрутизатор ISP должен выполнить поиск в таблице маршрутизации, чтобы узнать, знает ли он, где находится сеть 172.16.1.0 / 24.
Маршрутизатор ISP не знает, где находится 172.16.1.0 / 24, и отбросит IP-пакет.
Если бы это была настоящая производственная сеть, у нас не было бы доступа к маршрутизатору ISP. Так как это эмуляция сети и устройств, к которой у нас есть доступ, поэтому давайте сделаем отладку!
ISP#debug ip packet 1
IP packet debugging is on for access list 1
ISP#conf t
ISP(config)#access-list 1 permit host 192.168.34.4
Сначала включим отладку IP-пакетов и используем список доступа, который соответствует IP-адресу веб-сервера.
Следующим шагом является то, что мы будем генерировать некоторый трафик с хост-устройства.
Это то, что будет производить маршрутизатор ISP. Он говорит нам, что понятия не имеет, куда отправить IP-пакет для 172.16.1.1 to...it является не маршрутизируемым и будет отброшен.
Так как же мы решим эту проблему? ISP-маршрутизатор требует сеть 172.16.1.0 /24 в таблице маршрутизации. Поскольку мы уже запустили BGP мы можем использовать его для объявления этой сети с нашего маршрутизатора NAT:
NAT(config)#ip route 172.16.1.0 255.255.255.0 null 0
NAT(config)#router bgp 1
NAT(config-router)#network 172.16.1.0 mask 255.255.255.0
Сначала мы создадим статическое правило, которое указывает сеть 172.16.1.0 / 24 на интерфейс null0. Мы делаю это потому, что невозможно объявлять то, чего у тебя нет. Следующий шаг-объявить эту сеть в BGP.
Пинг прошел проблема решена!
Итог урока: убедитесь, что ваши маршрутизаторы знают, как связаться с translated сетями.
Урок 2
Начнем с простого сценария. Маршрутизатор с левой стороны - это наш DHCP-клиент, а маршрутизатор с правой стороны - это наш DHCP-сервер. Клиент, однако, не получает никаких IP-адресов ... что может быть не так?
Сначала мы проверим, включен ли интерфейс на клиенте DHCP и настроен ли он для DHCP. И это действительно так.
Мы также должны убедиться, что интерфейс на сервере DHCP включен/включен и что у него есть IP-адрес. Пока все выглядит хорошо...
Если мы хотим быть абсолютно уверенным, что проблема не в клиенте, нам надо применить отладку командой debug dhcp detail, чтобы посмотреть, отправляет ли клиент DHCP сообщения об обнаружении DHCP.
Мы видим некоторые отладочные выходные данные, как показано выше. Это говорит о том, что наш DHCP-клиент отправляет сообщения DHCP Discover. Клиент, скорее всего, не является источником этой проблемы.
DHCPServer#show ip dhcp pool
Мы будем использовать команду show ip dhcp pool, чтобы проверить, существует ли пул DHCP. Вы видите, что у нас есть пул DHCP с именем "MYPOOL", и он настроен для подсети 192.168.12.0 / 24. Пока все выглядит хорошо.
Мы можем использовать команду show ip dhcp server statistics, чтобы узнать, что делает сервер DHCP. Вы видите, что он ничего не делает ... что это может значить?
Эта команда не часто применяется. show ip sockets показывает нам, на каких портах роутер слушает. Как вы видите, он не прослушивает никакие порты ... если мы не видим здесь порт 67 (DHCP), это означает, что служба DHCP отключена.
DHCPServer(config)#service dhcp
Включим сервис.
Так-то лучше! Теперь мы видим, что маршрутизатор прослушивает порт 67, это означает, что служба DHCP активна.
Как только служба DHCP будет запущена, вы увидите, что клиент получает IP-адрес через DHCP ... проблема решена!
Итог урока: если все в порядке, убедитесь, что служба DHCP работает.
Урок 3
Взгляните на сценарий выше. У нас есть 3 маршрутизатора; маршрутизатор на левой стороне настроен как DHCP-клиент для своего интерфейса FastEthernet0/0. Маршрутизатор с правой стороны настроен как DHCP-сервер. Помните, что DHCP-сообщения об обнаружении от клиентов транслируются, а не пересылаются маршрутизаторами. Вот почему нам требуется команда ip helper на маршрутизаторе в середине, именуемым как relay. Проблема в этом сценарии заключается в том, что клиент не получает IP-адреса через DHCP
Сначала мы проверим, что интерфейс настроен для DHCP. Мы определим это с помощью команды show ip interface brief.
DHCPClient(config)#interface fastEthernet 0/0
DHCPClient(config-if)#shutdown
DHCPClient(config-if)#no shutdown
Мы будем переводить интерфейс в режимы up и down для проверки, будет ли он отправлять сообщение DHCP Discover.
Мы видим, что сообщения DHCP Discover принимаются на DHCP-сервере. Это означает, что маршрутизатор в середине был настроен с IP helper, в противном случае мы даже не получили бы эти сообщения. Сообщения с предложениями DHCP отправлены, но мы не видим сообщений DHCPACK (Acknowledgment). Это дает нам понять, что что-то происходит...
DHCPServer#debug ip dhcp server packet
Включим отладку, чтобы увидеть, что происходит.
Мы видим, что наш DHCP-сервер пытается достичь IP-адреса 192.168.12.2, это интерфейс FastEthernet0/0 нашего маршрутизатора в середине. Знает ли DHCP-сервер, как добраться до этого IP-адреса?
Как вы можете видеть, его нет в таблице маршрутизации, это означает, что IP-пакеты с назначением 192.168.12.2 будут отброшены.
Чтобы доказать это, мы можем включить отладку
Здесь видим, что IP-адрес назначения 192.168.12.2 не является маршрутизируемым, и в результате IP-пакет будет отброшен. Давайте исправим эту проблему.
DHCPServer(config)#ip route 192.168.12.0 255.255.255.0 192.168.23.2
Мы добавим этот статический маршрут, чтобы исправить нашу проблему с подключением.
Через некоторое время вы должны увидеть, что клиент получает IP-адрес через DHCP.
Если вы оставили "debug ip dhcp server packet" включенным, вы увидите весь процесс DHCP:
DHCP Discover
DHCP Offer
DHCP Request
DHCP ACK
Вот и все ... проблема решена!
Итог урока: если вы используете IP helper, убедитесь, что DHCP-сервер знает, как связаться с подсетью, в которой находится клиент.
3 часть статьи про FHRP траблшутинг на Cisco доступна по ссылке.
Компания Citrix предлагает сервера, приложения, виртуализацию, сетевые решения, программное обеспечение как услугу (SaaS) и облачные вычисления для бизнес-индустрии по всему миру. За плечами компании Citrix – богатая история помощи бизнесу достижения высоких позиций на рынке, а также продаж значительной части линейки продуктов LogMeIn в начале 2017 года.
История Citrix
Citrix Systems Inc – это американская компания, специализирующаяся на разработке программного обеспечения и приложений для облачных вычислений. Компания, основанная в 1989 году Эдом Якобуччи, бывшим сотрудником IBM, была известна как Citrus. Изначальный штаб сотрудников состоял из пяти инженеров, а в проект было инвестировано 3 миллиона долларов. Вынужденная сменить название после иска о нарушении прав на товарный знак, компания примкнула к бренду UNIX, чтобы создать имя, под которым она известна сейчас.
После этого компания осуществила первую аренду средств удаленного доступа для оборудования, работающего под управлением ОС Windows, разработанной Microsoft. Вскоре после этого компания перешла на разработку тонких клиентов, использовавшихся для удаленного доступа к серверам. Технология, которая позволила Citrix создать набор приложений для удаленного доступа, была разработана после присоединения ExpertCity и Sequoia Software в 2001 году.
По мере того, как компания Citrix присоединяла к себе другие компании, она расширяла свои возможности в сфере виртуализации настольного компьютера и серверов, увеличивая при этом число обслуживаемых клиентов. Идеальная площадка для запуска продуктов в области программного обеспечения как услуги (SaaS) и инфраструктуры как услуги (IaaS) Citrix обязана своим появлением технологии создания облаков.
Несмотря на то, что компания Citrix сконцентрировалась на разработке приложений по виртуализации, ассортимент фирмы GoTo, включая GoToAssist, GoToMeeting, GoToMyPC, объединенный в самостоятельное направление, стал широко использоваться среди бизнес-пользователей.
LogMeIn объявили о слиянии с Citrix в 2016 году, когда обе компании приобрели 50% долю в семействе GoTo, при этом средства для работы с удаленного доступа LogMeIn перешли на новый уровень интеграции со средствами для работы с удаленным настольным компьютером Citrix.
Штаб-квартира компании находится в Форт-Лодердейле, штат Флорида, и в Санта-Кларе, штат Калифорния. У Citrix также есть офисы в Роли (Северная Каролина), Австралии, Индии, Японии и Великобритании.
Компании, поглощенные Citrix
За 29-летнюю историю компания Citrix поглотила более 50 компаний, большинство из которых пополнили существующий ряд продуктов или помогли расширить зону влияния компании, не приводя к какой-либо радикальной диверсификации.
Первое поглощение состоялось спустя восемь лет после основания компании Citrix. Это была покупка австралийской фирмы DataPac, помогшей компании Citrix закрепиться в Азиатско-Тихоокеанском регионе (АТР). За последовавшее десятилетие компания Citrix сделала несколько важных приобретений, послуживших основой для запуска некоторых ключевых продуктов, в том числе Expercity, в 2004 году. Expercity повлекли за собой развитие комплекта GoTo-Netscaler в 2005 году, а в 2007 - XenSource, под чьим именем были выпущены XenApp и XenDesktop.
Одним из недавних приобретений компании была Cedexis, купленная в феврале 2018 года. Компания Citrix купила ее для «оптимизации производительности приложений и контента в мире гибридных мульти-облачных вычислений», как говорится в заявлении генерального директора по разработке продукции.
Последнее на данный момент поглощение платформы для микро-приложений Sapho было завершено в 2018 году и обошлось компании в 200 миллионов долларов. Компания Citrix планирует напрямую внедрить технологию Sapho, чтобы повысить осведомленность сотрудников.
Между тем Стив Шах, вице-президент по управлению продуктами, прокомментировал это так: «IT-специалисты будут способны реагировать быстрее и действовать лучше при устранении неполадок в сети, управлении нагрузкой облаков и обработке изменений емкости в соответствии с нуждами бизнеса. Более того, IT-отдел сможет сократить сетевые и облачные расходы, обеспечивая при этом наилучшее качество взаимодействия с пользователем».
Что продает Citrix?
Все продукты Citrix можно разделить на три линии: Workspace, Networking и Analytics. До масштабного ребрендига, состоявшегося в мае 2018 года, всего через несколько дней после ежегодного мероприятия Synergy, компания так же предлагала приборы для удаленного доступа под брендом Xen.
Эти продукты, известные ранее как XenApp, XenDesktop и XenMobile, сейчас переименованы в Citrix Virtual Apps, Citrix Virtual Desktops и Citrix Endpoint Management соответственно, теперь подпадают под Citrix Workspace наряду с Citrix Hypervisor, ранее XenServer, и Citrix Content Collaboration, ранее ShareFire, среди прочих продуктов.
Virtual Apps обеспечивают поддержку для приложений, Virtual Desktops поддерживают удаленный доступ к рабочему столу. Hypervisor - это платформа для виртуализации серверов, обеспечивающая лучшую производительность приложений и настольных ПК. Endpoint Management, входящая в эту ветвь производства Citrix, является гарантом мобильности компании.
Content Collaboration - это продукт Citrix для синхронизации и обмена файлами, помогающий компаниям обмениваться контентом локально и в облаке с другими сотрудниками, такими как коллеги и клиенты.
Компания Citrix также предлагает ряд сетевых продуктов, которые она приобрела у Netscaler - название, существование которого также прекратилось в процессе ребрендинга 2018 года. Citrix Networking, вторая линия продуктов, включает Citrix ADC, Citrix Web App Firewall, Citrix Gateway, Citrix Application Delivery Management, Citrix SD-WAN. Все они способны помочь предприятиям работать лучше. Их можно задействовать и в центре обработки данных, и в филиале, и в облаке и на мобильном телефоне.
Citrix Analytics, третья линия продуктов, применяет машинное обучение для обеспечения анализа поведения пользователей и проактивного анализа безопасности. Продукты этой линии собирают данные по всему портфелю Citrix, генерируя действенные идеи, позволяющие администраторам обрабатывать угрозы безопасности пользователей и приложений, отслеживая потенциальные уязвимые места в организации.
Citrix на бизнес-арене
Citrix является публичной компанией, котирующейся на фондовой бирже NASDAQ.
Результаты за четвертый квартал 2017 года показали рост выручки на 6% по сравнению с аналогичным периодом прошлого года (778 миллионов долларов США против 735 миллионов долларов США). Большая часть этого роста была обеспечена подразделением «Программное обеспечение как услуга» (рост на 38% в годовом исчислении) и профессиональными услугами (рост на 13% в годовом исчислении). В целом за 2017 год годовой доход составил 2,82 млрд. долларов против 2,74 млрд долларов в 2016 году, увеличившись на 3%. Большая часть этого роста также пришлась на подразделение SaaS (рост на 31% в годовом исчислении). Операционная маржа компании по GAAP за год составила 20%.
В 2018 году компания частично опровергла ожидания аналитиков в отношении чистой выручки, составляющей от 2,86 млрд. До 2,88 млрд. долларов, зафиксировав годовой доход в размере 2,97 млрд. долларов, равный увеличению на 5%. Это проявилось в 4% -ном снижении доходов от продуктов и лицензий по сравнению с аналогичным периодом прошлого года, и в увеличении количества подписок на 45%. Между тем, доходы от поддержки и услуг выросли на 2%. Цена на акции Citrix резко выросла к концу 2019 года, достигнув рекордной отметки в 128 долларов 23 января этого года, немного снизившись в продолжении.