Pull to refresh
58
0
Eugene Glotov @KIVagant

User

Send message
Так много написано, но совершенно непонятно о чём речь.

> Постоянную тонкой структуры ввели в 1916 году для количественной оценки промежутков между двумя линиями в спектре цветов, испускаемых определёнными атомами. На фото плотно расположенные частоты видны через резонатор Фабри — Перо

Зачем ввели? Каких промежутков? Каких линий? Каких цветов? Что за резонатор? О чём вообще эта статья?
Ещё юридическая составляющая. В штатах всё делается медленно и дорого. Проложить куда-то там кабель по чужим крышам и колодцам не получится.
Век живи, век учись. Уже сколько всего под Jenkins делал, а такой тип параметров ни разу не пробовал. Спасибо, пригодится.
Откровенно говоря, статья ни о чём.
Вы мой герой! Отличный пример, спасибо! Будет теперь с чем поразвлекаться!
Конечно можно и без. Только в любом случае нужен анализ текста, чтобы определять род, склонение, отсутствие уже существующих окончаний и так далее. Мне кажется тут есть место и для варианта с нейронками.
Немного оффтопик. Давно у меня блуждает идея написать расширение к браузеру, которое на новостных сайтах будет автоматически дописывать ко всем заголовкам новостей желтушные окончания вроде:
— "… и попала на видео"
— "… и сгорел от стыда"
— "… и опозорились"
— "… и был пристыжен"
— "… и была высмеяна в соцсетях"
и так далее.
Может кто-то имеет хороший опыт работы с нейронками и знает, как это делается быстро?
Нет, конечно. Просто сразу на ум пришло. Google Cloud — очень свежее «облако», выбирая его люди получают лучшую цену, но теряют как раз в богатстве и, главное, надёжности функционала.
> Создав БД в американском регионе, сделать read-реплику в европейском регионе средствами Cloud SQL нельзя, хотя сам постгрес этого делать не мешает.

aws.amazon.com/about-aws/whats-new/2016/06/amazon-rds-for-postgresql-now-supports-cross-region-read-replicas
Поддерживаю. Я видел уже этот плагин здесь ранее, но пришлось вспоминать контекст.
Учитывая что у них нет тестов и нет желания их писать, любой рефакторинг увеличит количество багов с 26 до 134
>знаю немало админов, которые хранят всю свою личную и рабочую переписку с начала времен.

В открытом виде на домашнем ПК и не на незашифрованных носителях? :) Это не админы.
Если у вас есть grpc и вы деплоитесь в Kubernetes, то у вас в общем-то не будет большого выбора внедрять или не внедрять service mesh.
Так как горячие головы могут уверовать в технологию, сразу сообщаю, что всё будет не так просто. Есть некоторое количество серьёзных issue как в Linkerd2, так и в самом Kubernetes, которые если не препятствуют, так точно серьёзно усложняют обслуживание service mesh, при чём не только Linkerd.

Кроме того чисто технически растут накладные расходы, об этом в статье упомянуто. А вот о чём не сказано, так это то, что по-умолчанию Linkerd устанавливает MutatingWebhookConfiguration на который условно можно полагаться только в самых свежих версиях Kubernetes. Да и то я бы не рискнул, уж очень неприятные сайд-эффекты при проблемах. Так что automatic sidecar injection стоит заменять на ручную через CI, которая менее зависима от событий кубернетиса и не вызывает падение всего кластера в случае отказов.

В статье также не указывается одна важная мысль: linkerd в виде sidecar proxy НЕ является Ingress Controller. И все преимущества в виде retry/… НЕ будут доступны для внешних пользователей по-умолчанию, если ваш Ingress не встроен в service mesh. То есть это прежде всего _между сервисная коммуникация внутри кластера_, а не балансировщик нагрузки пользовательских запросов. А вот Linkerd v1 могла выполнять и функцию балансировки для конечных потребителей.

А ещё для того же Canary требуются сторонние тулзы.
> из которого убрана большая часть логики

Битрикс… Как вспомню так вздрогну.
> 3,5 сек до первой сотни! А у меня ведь ещё семья

Прям нарочно не придумаешь…
> Откуда информация про планирование по лимитам?

Это уже у меня смешались в кучу конелюди. Планирует он по requests, это я некорректно сформулировал свою мысль. Была какая-то проблема, с которой я боролся пару месяцев назад. Вспомню, вернусь.
Квоты хорошая штука, безусловно. Но с ними усложняется мониторинг. Если ReplicaSet не может создать под из-за квот, то под не виден в списке (возможно в более новых куберах уже улучшили это). В итоге нужно изобретать сложные проверки, чтобы заметить, что есть Replicasets, у которых ожидаемое количество подов не совпадает с желаемым. Тем не менее я также за их установку. Но вот беда в том, что сами resource requests и limits далеко не так просты, как хочется. Например, лимиты на CPU могут существенно снижать производительность кластера. А с лимитами на ephemeral storage вообще крайне сложно, так как невозможно получить реальное использование по этой метрике.
И дополнительной вишенкой является работа самого планировщика. По-умолчанию он планирует поды по limits, а не по requests. И если установить поду/контейнерам RAM request в 100Mb, а limit в 16Gb, то этот под «зарезервирует» ноду целиком.

Плюс есть какая-то странность в том, что поды в статусе Completed всё ещё учитываются в квотах по namespace (тут вероятно тоже могут быть отличия в более новых версиях). В итоге квоты приходится раздувать.

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity