Dronenet ingress что это
Dev Diary: Dronenet
We originally teased the concept of the Dronenet in the Niantic Project ARG before Ingress released in Nov 2012. Eagle-eyed Agents may recall Drone Footage of California City, CA that led back to Roland Jarvis, or videos shared by Ben Jackland. Dronenet Canisters were also dead dropped for Campus Agents in New York, SF, LA, and Austin, which included Closed Beta invites and passcodes for gear.
We’re releasing Dronenet now in Ingress 2.48 as a “Mark I” so we can hear early feedback from Agents to help us shape the direction of how the feature may evolve over time. We’ll launch and iterate. In the next Ingress update, we have the first Dronenet improvements already scheduled, like a visible cooldown timer to make it easier to see the time remaining before your Drone is ready to move. We’re especially eager to experiment with different ways to play using Dronenet to explore an area, from Portal to Portal.
Dronenet allows Agents to deploy Drone Mark I to any neutral, friendly, or enemy Portal within view on the map screen. Agents can hack a Target Portal for items once per Drone flight, and the Drone can move once every 60 minutes. It can’t be used to retrieve a Portal Key or take any other action. It does count as a Drone hack towards Sojourner, but it can’t be used to complete a mission or as a proxy for event attendance — these will continue to require your physical participation.
For more info on how to access Dronenet and deploy Drone Mark I, please see our Help Center article.
The specific functionality of Mark I is intentional as a Mark I starting point. There are several different ways Mark I might be used by Agents: Agents may compete for Furthest Drone Flight (the furthest distance traveled hopping from Portal to Portal from the initial Start Portal), or use Drone Mark I to help farm L8 gear and practice Glyph hacking. But there are many possible paths a new Mark II or Mark III Drone could take, and we’d love to hear your feedback and suggestions.
At its core, Ingress will continue to enable outdoor adventures with friends, and our intention with Dronenet is to help give Agents even more ways to play. You can access Dronenet today in Ingress 2.48 by tapping the Main Menu button, then selecting Dronenet. We’re working to deliver the Mark I to all Agents now so if you aren’t yet seeing Dronenet in the Main Menu, stay tuned.
Ingress — Ответы на вопросы и некоторые секреты
От автора топика
Инвайт пришел достаточно быстро. Прочитав этот замечательный пост, я не нашел ответы на многие вопросы… Даже пробежавшись пару часов, связав пару порталов и прокачав их по самое «нехочу» все равно остались вопросы. Google и один продвинутый друг помог во всем разобраться, о чем я и решил поделиться с сообществом, немного дополнив и расширив лучший найденный мануал. Предложения по лучшей русской терминологии предлагайте в комментариях. Буду апдейтить статью.
О Ингресс
Ингресс — это игра с дополненной реальностью в которой нужно идти в конкретные реальные места и взламывать порталы. В игре есть две фракции: Enlightened (Просвещенные) и Resistance (Сопротивление).
Широко популярный в узких кругах Niantic Project был вирусной рекламой этой заманухи.
История, лежащая в основе
Научный эксперимент в CERN создал цепную реакцию выпустившую необычную энергию (XM) по всему миру. В результате сформировались порталы в таких местах как памятники, музеи и другие публичные места. Обе фракции пытаются захватить эти порталы и установить резонаторы, для генерации еще большего количества энергии. Если связать три портала, то в пространстве между ними будет создано поле, защищающее от Shapers (Шейперов).
Присоединение к Просвещенным
Фракция пытается помочь Шейперам проникнуть на Землю. Последователи верят, что Шейперы принесут великое просвещение, которое обеспечит великий прорыв для всего человечества.
Присоединение к Сопротивлению
Фракция защищает Землю от вторжения Шейперов. Это люди опасающиеся прогресса, но Сопротивление сильно убеждено, что они защищают человечество.
Как играть?
Существует возможность создавать порталы
Секретные фразы
В этом чудесном гуглодоке есть ключи, которые дают безумное количество плюшек. Ключи добываются расследованиями на сайте Niantic Project.
Взлом и захват порталов
Когда вы приближаетесь к вражескому порталу вы можете его атаковать с помощью XMP и в конце концов взломать его. Вероятность взломать вражеский портал гораздо ниже.
Дополнительная информация
P.S. На данный момент сопротивление стремительно теряет позиции.
Сам я пожалуй переметнусь на сторону просвященных, т.к. когда я выбирал принадлежность к сопротивлению идеологическая сторона вопроса была не ясна.
P.P.S. Вокруг Кремля завязалась серьезная борьба. До красной площади — 30 минут пешком, и около 50 порталов. Обойма полна патронов (зарядку Ингресс жрет немеряно). На 2-3 часа хватит. К полуночи отобъем позиции.
UPD. Игра жестко следит за настройкой fake GPS connection.
Kubernetes Ingress глазами новичка
Ingress это базовый тип ресурса в кубертенесе. Если просто объявить объект типа Ingress в кубернетисе то ничего не произойдет.
Что бы этот ресурс начал работу в кластере кубернетиса должен быть установлен Ingress Controller, который настроит реверсивный прокси в соответствии с Ingress объектом.
Ingress Controller состоит из 2х компонентов — реверсивного прокси и контроллера который общается с API сервером кубернетеса. Реверсивный прокси слушает входящий трафик на портах которые указаны в настройках (обычно в настройках по умолчанию указан только порт 80). Контроллер может быть как отдельным демоном (как в nginx), так и встроенным в прокси (как в traefik).
Не все клауд провайдеры кубернетеса предустанавливают Ingress Controller по умолчанию.
Контроллеры могут запускаться либо как DaemonSet либо как Deployment. DaemonSet идеально использовать как единственный Ingress Controller, что бы реверсивное прокси слушало на всех IP адресах воркеров. Deployment отлично подходит если перед Ingress контроллером стоит балансировщик — от провайдера кубернетиса (GKE, AKS), MetalLB если онпремис или обычный haproxy/nginx установленный на сервере (требутеся ручная настройка). При этой установке возможно установить несколько Ingress Controller.
Как входящий трафик попадает на Ingress Controller
Во всех случаях реверс прокси в Ingress Controller слушает порты где ожидает http/https соединения.
Трафик на этоти порты может попасть тремя путями:
NodePort
Ставить Ingress Controller на NodePort без LoadBalancer имеет мало смысла, так как URL будет включать порт который указан в NodePort http://domain.example.org:32200/.
Для этого варианта лучше использовать Deployments. Это позволит проще скейлить количество подов ответственных за входящий трафик, прописывать им nodeAffinity и запускать несколько ingress controller (например для production и staging).
HostPort
При использовании HostPort порт пробрасывается с хоста где запущен под в этот самый Pod. LoadBalancer на вход не нужен, но для работы сайта в DNS нужно указывать что адрес домена находится на всех узлах.
Пример конфигурации DNS для 3х воркеров:
Для этой установки лучше всего использовать DaemonSet т.к. он позволяет запустить не более одного Pod на хосте. Deployment возможен, но имеет мало смысла т.к. надо прописывать affinity что бы не назначилось 2 Pod на один хост, иначе будет конфликт по портам.
Host network
При запуске Ingress Controller в общей сети с хостом не требуется никаких пробросов портов, но в этом случае все порты которые открыты в Pod будут доступны из интернета. Для запуска лучше использовать DaemonSet. Причины такие же как и с HostPort — что бы избежать конфликта портов.
Что выбрать
Если есть LoadBalancer на входе — NodePort, если нет — HostPort + DNS Round Robin. Для экспериментов можно попробовать Host network, но это не безопасно.
Сети Kubernetes: Ingress
Сегодня мы публикуем перевод третьей части руководства по работе с сетями в Kubernetes. В первой части речь шла о подах, во второй — о сервисах, а сегодня мы поговорим о балансировке нагрузки и о ресурсах Kubernetes вида Ingress.
Маршрутизация — это не балансировка нагрузки
Кажется совершенно очевидным то, что любой механизм, который мы используем для того, чтобы позволить внешним клиентам обращаться к подам, должен использовать эту же инфраструктуру маршрутизации. В результате эти внешние клиенты будут обращаться к IP-адресу и порту кластера, так как они являются «точкой доступа» ко всем тем механизмам, о которых мы до сих пор говорили. Они позволяют нам не беспокоиться о том, где именно выполняется под в некий определённый момент времени. Однако совсем неочевидно то, как сделать так, чтобы всё это работало.
Кластерный IP сервиса достижим лишь с Ethernet-интерфейса узла. Ничто за пределами кластера не знает о том, что делать с адресами из диапазона, к которому принадлежит этот адрес. Как можно перенаправить трафик с общедоступного IP-адреса на адрес, который достижим только в том случае, если пакет уже пришёл в узел?
Внешний клиент и кластер
Если настроить всё именно так, то такая конструкция окажется рабочей. Клиенты обращаются к кластерному IP, пакеты следуют по маршруту, ведущему их к узлу, а затем перенаправляются поду. В этот момент вам может показаться, что таким решением можно и ограничиться, но оно страдает некоторыми серьёзными проблемами. Первая заключается в том, что узлы, вообще-то, понятие эфемерное, они не особенно отличаются в этом плане от подов. Они, конечно, немного ближе к материальному миру, чем поды, но они могут мигрировать на новые виртуальные машины, кластеры могут масштабироваться вверх или вниз, и так далее. Маршрутизаторы работают на третьем уровне модели OSI и пакеты не могут отличить нормально работающие сервисы от тех, что работают неправильно. Они ожидают, что следующий переход в маршруте будет доступен и окажется стабильным. Если узел оказывается недостижимым, маршрут станет нерабочим и будет таким оставаться, в большинстве случаев, немало времени. Если даже маршрут окажется устойчивым к сбоям, то такая схема приведёт к тому, что весь внешний трафик пойдёт через единственный узел, что, вероятно, оптимальным не является.
Как бы мы ни приводили клиентский трафик в систему, нам надо это делать так, чтобы это не зависело бы от состояния любого отдельно взятого узла кластера. И, на самом деле, нет надёжного способа сделать это, используя лишь маршрутизацию, без неких средств активного управления маршрутизатором. Собственно говоря, именно подобную роль, роль системы управления, kube-proxy играет по отношению к netfilter. Расширение сферы ответственности Kubernetes до управления внешним маршрутизатором, вероятно, не имело особого смысла для архитекторов системы, особенно учитывая то, что у нас уже есть доказавшие свою полезность инструменты для распределения клиентского трафика между множеством серверов. Они называются балансировщиками нагрузки, и неудивительно то, что именно они являются действительно надёжно работающим решением для Kubernetes Ingress. Для того чтобы понять то, как в точности это происходит, нам нужно подняться с третьего уровня OSI и снова поговорить о соединениях.
Для того чтобы использовать балансировщик нагрузки для распределения клиентского трафика между узлами кластера, нам нужен общедоступный IP-адрес, к которому могут подключаться клиенты, а так же нам нужны адреса самих узлов, на которые балансировщик нагрузки может перенаправлять запросы. По вышеописанным причинам мы не может просто создать стабильный статический маршрут между шлюзом-маршрутизатором и узлами, используя сеть, основанную на сервисах (IP кластера).
Балансировщик нагрузки, неудачная попытка обращения к порту 80 сетевого интерфейса узла
Сервисы типа NodePort
После того, как эта часть системы заняла своё место, у нас есть все фрагменты конвейера для балансировки нагрузки, создаваемой запросами клиентов ко всем узлам кластера.
Этот механизм, однако, не лишён собственных проблем. Использование сервисов типа NodePort даёт клиентам доступ к сервисам с использованием нестандартного порта. Часто проблемой это не является, так как балансировщик нагрузки может предоставить им обычный порт и скрыть NodePort от конечных пользователей. Но в некоторых сценариях, например, тогда, когда используется внешний балансировщик нагрузки платформы Google Cloud, может быть необходимым раскрыть NodePort клиентам. Надо отметить, что такие порты, кроме того, представляют собой ограниченные ресурсы, хотя 2768 портов, вероятно, достаточно даже для самых больших кластеров. В большинстве случаев можно позволить Kubernetes выбирать номера портов случайным образом, но при необходимости их можно задавать самостоятельно. Ещё одна проблема заключается в некоторых ограничениях, касающихся сохранения IP-адресов источников в запросах. Для того чтобы выяснить способы решения этих проблем, вы можете обратиться к этому материалу из документации Kubernetes.
Порты NodePorts — это фундаментальный механизм, благодаря которому весь внешний трафик попадает в кластер Kubernetes. Однако сами по себе они не представляют нам готового решения. По вышеозначенным причинам перед кластером, являются ли клиенты внутренними или внешними сущностями, находящимися в общедоступной сети, всегда требуется иметь некий балансировщик нагрузки.
Архитекторы платформы, понимая это, предоставили два способа задания конфигурации балансировщика нагрузки из самой платформы Kubernetes. Давайте это обсудим.
Сервисы типа LoadBalancer и ресурсы вида Ingress
Архитекторы могли бы здесь и остановиться, позволив тем, кто создаёт кластеры, заботиться лишь об общедоступных IP-адресах и балансировщиках нагрузки. На самом деле, в определённых ситуациях, в таких, как запуск кластера на обычных серверах или в домашних условиях, именно так и поступают. Но в окружениях, которые поддерживают конфигурации сетевых ресурсов, управляемые через API, Kubernetes позволяет настроить всё, что нужно, в одном месте.
Выше сказано, что удостовериться в факте назначения внешнего IP-адреса мы сможем «вскоре», несмотря на то, что назначение внешнего IP может занять несколько минут, что неудивительно, учитывая количество ресурсов, которые нужно привести в работоспособное состояние. На платформе GCP, например, для этого нужно, чтобы система создала внешний IP-адрес, правила перенаправления трафика, целевой прокси-сервер, бэкенд-сервис, и, возможно, экземпляр группы. После выделения внешнего IP-адреса к сервису можно подключиться через этот адрес, назначить ему доменное имя и сообщить клиентам. До тех пор, пока сервис не будет уничтожен и создан повторно (для того, чтобы это сделать, редко когда находится достойный повод), IP-адрес меняться не будет.
У сервисов типа LoadBalancer есть некоторые ограничения. Такой сервис нельзя настроить на расшифровку HTTPS-трафика. Нельзя создавать виртуальные хосты или настраивать маршрутизацию, основанную на путях, поэтому нельзя, строя конфигурации, применимые на практике, использовать единственный балансировщик нагрузки со множеством сервисов. Эти ограничения привели к появлению в Kubernetes 1.1. особого ресурса, предназначенного для конфигурирования балансировщиков нагрузки. Речь идёт о ресурсе вида Ingress. Сервисы типа LoadBalancer нацелены на расширение возможностей отдельно взятого сервиса по поддержке внешних клиентов. В отличие от них, ресурсы Ingress — это особые ресурсы, которые позволяют гибко настраивать балансировщики нагрузки. API Ingress поддерживает расшифровку TLS-трафика, виртуальные хосты, маршрутизацию, основанную на путях. С помощью этого API балансировщик нагрузки легко можно настроить на работу с несколькими бэкенд-сервисами.
HostPort и HostNetwork
Я думал, что о них и вовсе не стоит говорить, но они представляют собой нечто вроде тех средств, которые используются ресурсами Ingress для обработки входящего трафика, поэтому я решил, что о них стоит, хотя бы кратко, упомянуть.
Итоги
Сегодня мы поговорили о маршрутизации в сетях Kubernetes, о балансировке нагрузки, об особенностях использования сервисов разных типов и ресурсов вида Ingress. Надеемся, серия статей, которая завершается этим материалом, помогла вам лучше разобраться в тонкостях Kubernetes.
Уважаемые читатели! Пользуетесь ли вы ресурсами Ingress?
Ingress
Ingress — Android/iOS игра от Google. Место действия — альтернативная реальность.
Фабула заключается в том, что учеными из Европы была открыта некая мистическая энергия.
Показать полностью. Что за энергия и откуда она — никто не знает, но некоторые исследователи полагают, что она влияет на то, как мы думаем. Так что мы должны ее контролировать, или она будет контролировать нас.
Вам предстоит занять одну из сторон:
— The Enlightened (Просвещённые)
Просвещенные не видят вреда в Шейперах. Свидетельства присутствия Шейперов прослеживается на протяжении всей истории в каждом известном творческом человеке или лидере, которые слышали «гласы свыше», направлявшие их. Шейперы веками направляли человечество и, посмотрите, во всем влияние Шейперов. Просвещенные хотят увеличить это влияние, чтобы направить нас в новую эру человека.
— The Resistance (Сопротивление)
Сопротивление борется за то, чтобы не допустить влияния Шейперов на человечество. Они считают, что люди перестанут быть индивидуальностями и станут коллективным разумом. Считают, что Шейперы не подают идеи, а вместо этого просто позволяют идеям распространяться быстрее, а также с какой-то гнусной целью манипулируют творческими способностями людей. Также считают, что Шейперы всегда существовали на другом уровне реальности, но всегда хотели перебраться на наш и не могли это сделать без помощи человеческих тел.
Установленное на смартфон приложение будет проводить вас по местам скопления «Экзотической материи» (реальные географические координаты, которые надо будет посетить).
Важную роль здесь играет командная игра — вашей фракции нужно получить контроль над порталами энергии и создать зону, которую фракция сможет контролировать. Ну и отвоевывать такие же зоны, созданные врагами.
Крупнейшее русское сообщество игроков Ingress на Android и iOS Вконтакте(Россия). Инструкции по-русски, помощь, новости, аномалии, филд-арты, юмор.