Здравствуйте, Cyberax, Вы писали:

C>У меня K8S работает на Raspberry Pi.

Хеллоуворлды где угодно запустятся

C>Ещё один воинствующий неумеха появился в теме.

Это не я, это пересказываю впечатления отдела внедрения. Мне с такими субстанциями возиться по долгу службы не довелось, слава богу.

Здравствуйте, Sheridan, Вы писали:

Вот поэтому липунс и идет на йух

Здравствуйте, Sheridan, Вы писали:

S>Докер нужен всегда, везде и кубернетес пророк его -> глупость.
S>Надо ложить на актуализацию используемых в проекте либ -> глупость.
S>Изоляция строго необходима -> глупость.

У тебя что-то приключилось? Генту не компилируется? Потому что иначе ты бы еще сказал, что программировать на управляемых языках — глупость, что умные указатели — глупость, ну и что там еще по списку.

Здравствуйте, Marty, Вы писали:

M>Вот поэтому липунс и идет на йух
Дадада. Идёт-идёт. На юх, именно туда. Успокойтесь, всё хорошо. Давайте шнурочки подзатяну...

Здравствуйте, Michael7, Вы писали:

M>Здравствуйте, Mamut, Вы писали:

M>>В идеале так и нужно. Жалко, unikernels так до вменяемого состояния и не допилились, они бы в теории были бы неплохой альтернативной докеру.

M>Может быть, я как-то про них вообще мало знаю.

Идея в юникернеле в том, что у тебя есть абсолютно самый минимальный набор системы и библиотек, чтобы приложение запустилось. И запускается напрямую на гипервизоре или прямо железе. То есть, условно говоря, если твое приложение требует только I/O (а это примерно 99.9999% микросервисов), то собирается образ, состоящий только из boot loader'а, io и только того рантайма, который строго необходим твоему приложению.

Потому что даже с докером у тебя все равно на фоне чуть ли не полноценная ось (или даже полноценная, потому что люди часто не думая основывают прям на какой-нить Ubuntu), в которую запиливается полноценный рантайм (например, весь jre), и это все взлетает.

Но для этого надо перепиливать ОСи и/или рантаймы языков, а заниматься этим мало кто хочет. Знаю, что люди достигали миллисекундого отклика с холодного старта даже для Erlang'а. Но на практике почти все такие проекты или уже мертвы (как Ling) или в состоянии перманентного застоя (то есть работают только для одного-двух языков как MirageOS для OCaml'а).

Здравствуйте, Michael7, Вы писали:

M>Здравствуйте, Mystic Artifact, Вы писали:

MA>> Разработчикам делать нехер как следить за всякими дистрибутивами. Нормальному приложению должно быть пофигу на либы в дистрибутиве, настолько, насколько это возможно. Именно так достигается переносимость между пачками дистрибутивов да еще в одном бинарнике.

M>С одной стороны да, с другой все же если делается Продукт, неплохо бы и последить за хотя бы самыми популярными, вроде Ubuntu, Debian, Fedora, CentOS/RHEL. Обычно, если под ними работает, то и под другими дистрами пользователь сможет более-менее легко запустить. Косвенно, переносимость вообще улучшает качество кода.

M>Потому что иначе возникают ситуации, когда разработанный софт (новая версия) работает почти исключительно на машине разработчика и более нигде, после чего он свое окружение пакует в докере и распространяет. Ну в принципе да, решение проблемы, но в итоге можно прийти к тому, что каждая программа будет в своем снапшоте сидеть.

Это лучше оставить создателям десктопных компонент. Или библиотек, поcле сильной унификации

Если это микросервисный или кластерный компонент, то будет лучше, если разработчик не будет изучать выгон разных service managers и прочей специфичной "радости". А сделает минималистичный образ с четко обозначенными библиотеками. И хорошо отладит продукт. Один компонент — одна функция, иначе все силы уйдут на поддержание "всемогутора"

В конце концов, для микросервисов ОС вырождается в "запускалку кубернетес/Mesos/..." и больше ничего не надо

Здравствуйте, smeeld, Вы писали:

C>>У меня K8S работает на Raspberry Pi.
S>Хеллоуворлды где угодно запустятся
Я использую K8S локально на одном ноуте для разработки. Не надо мне сказок рассказывать про "супертребования".

C>>Ещё один воинствующий неумеха появился в теме.
S>Это не я, это пересказываю впечатления отдела внедрения. Мне с такими субстанциями возиться по долгу службы не довелось, слава богу.
Ага, Рабинович напел. Понятно. Или у вас там Шеридан работает?

Здравствуйте, Sheridan, Вы писали:

S>>>А знаешь причины этого? Подсказать? Или догадаешься из контекста всего этого срача?
MA>> Грубить не надо. Я тебя ни в чем не обвинял, лишь спрашивал как ты себе это все представляешь. Ответ на свой вопрос я получил.
S>Извини если грубо. Причины описанной ситуации то понял?
Я писал, что при изменении внешних зависимостей, мало что можно гарантировать, в случае, если они меняются вне зависимости от нас. Ты ж про это? Я не вижу тут большого поля для обсуждения честно говоря, и что ты подразумеваешь под причинами этого. Поэтому скорее не понял, чем понял.

Здравствуйте, Michael7, Вы писали:

M>Здравствуйте, Mamut, Вы писали:


M>Но стремление все пихать в докеры чудовищно раздувает ресурсы. Собственно об этом уже рядом ответили. Одно дело, когда в докерах одно-два жирных, тяжелых приложения, совсем другое если они чуть не на каждый чих, а так и будет в итоге, если перестать следить, чтобы софт работал хотя бы на самых популярных LTS дистрах. Кроме того, докер все же не панацея, если сильно не повезет, в нем тоже работать не будет.

Чудовищно, это сколько? В процентах, с примерами, если не брать образы от новичков, где в базовый полный Ubuntu запихан

Из всех что я видел, это базовый образ Windows отъедает заметное пространство но и он с каждой ревизией худеет.

По Runtime памяти, конкретный пример (на машине 16Gb)

____________________________________________________________________________________

kworker@L17:~$ top -b -o +%MEM | head -n 22
top - 12:38:14 up 8 days, 18:37,  1 user,  load average: 1.29, 1.53, 1.70
Tasks: 253 total,   1 running, 252 sleeping,   0 stopped,   0 zombie
%Cpu(s):100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  15998.4 total,  10136.7 free,   4820.5 used,   1041.3 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.  11955.6 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
1669136 root      20   0  147.8g   2.2g 604440 S 175.0  14.0   1032:50 influxd
1098394 nobody    20   0   10.1g 387336   8568 S   0.0   2.4 383:54.17 prometheus
   1406 root      20   0 1359200  76000  19236 S  12.5   0.5 302:16.98 kubelet
   1447 root      20   0 1412512  75480   2288 S   0.0   0.5 182:08.14 dockerd
   1435 root      20   0 1486852  51464  15480 S   0.0   0.3  18:05.37 containerd
1098433 472       20   0  162960  48524  12020 S   0.0   0.3  32:28.45 grafana-server
    440 root      19  -1  213248  34856  33572 S   0.0   0.2   0:54.52 systemd-journal
1614203 systemd+  20   0  755608  27660   3260 S   0.0   0.2   2:50.50 argocd-server
   1414 root      20   0  940744  20896    828 S   0.0   0.1   0:25.50 snapd
    851 root      20   0  280452  18128   8184 S   0.0   0.1   0:44.63 multipathd
1613937 systemd+  20   0  751180  15032      0 S   0.0   0.1   2:58.23 argocd-applicat
   2616 root      20   0  140100  14656   1820 S   0.0   0.1   4:06.44 kube-proxy
1614447 1001      20   0  745152  13048    612 S   0.0   0.1   0:25.93 argocd-util
   3763 root      20   0  133068  12380   2216 S   0.0   0.1   3:29.46 local-provision
   3816 root      20   0  182860  12132     40 S   0.0   0.1  16:30.10 consul

____________________________________________________________________________________



См. kubelet, dockerd, containerd, kube-proxy


Личный кластер на 1-м VPS, 4Gb RAM:

______________________________________________________________________________

vetal@utility:~$ top -b -o +%MEM | head -n 22
top - 17:42:44 up 12 days, 23:40,  1 user,  load average: 0.51, 0.52, 0.49
Tasks: 193 total,   1 running, 149 sleeping,   0 stopped,   0 zombie
%Cpu(s):  7.0 us,  3.3 sy,  0.0 ni, 85.5 id,  3.9 wa,  0.0 hi,  0.1 si,  0.2 st
KiB Mem :  4039156 total,   370540 free,  1538576 used,  2130040 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  2329644 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  763 root      20   0  722420 571560  85952 S   5.9 14.2   1762:20 k3s-server
 1165 root      20   0  223844 135476  73376 S   0.0  3.4 194:02.64 containerd
  416 root      19  -1  205248 107344  98716 S   0.0  2.7   0:38.90 systemd-journal
 6664 999       20   0 1776288 100668  23248 S   0.0  2.5   8:55.08 mysqld
  895 root      20   0  904964  83560  45912 S   0.0  2.1   6:39.33 dockerd
 2398 root      20   0  165796  71660  38492 S   0.0  1.8  31:11.08 traefik
24573 2016      20   0  170536  61228   4508 S   0.0  1.5  28:21.88 gunicorn
24572 2016      20   0  169484  59928   4524 S   0.0  1.5  29:34.47 gunicorn
24575 2016      20   0  169232  59604   4504 S   0.0  1.5  30:01.46 gunicorn
10063 www-data  20   0  323764  58216  38500 S   0.0  1.4   0:03.24 apache2
10040 www-data  20   0  323692  57956  38500 S   0.0  1.4   0:03.80 apache2
 8412 www-data  20   0  323608  57856  38500 S   0.0  1.4   0:02.33 apache2
 2809 root      20   0  198260  57240  44592 S   0.0  1.4  13:20.16 vault
10062 www-data  20   0  322436  57192  38884 S   0.0  1.4   0:03.71 apache2
 4564 www-data  20   0  323204  56984  39076 S   0.0  1.4   0:29.97 apache2

_____________________________________________________________________________


См. k3s-server, dockerd, containerd

Это k3s, разворачивается одной командой


Чудовищные ресурсы это зарплата любителей плуга и мотыги, расход личного времени. И у "страха глаза велики" для людей поленившихся проверить лично.

Здравствуйте, smeeld, Вы писали:


S>Это всё как раз не про несчастный глючный докер. Если у тебя софт -не маленькая программулька aka сайтик на lamp, а целый кластер, то, чтоб энтот кластер в виде кубернетиса на машину вкорячить нужно:
S>1) отдельная мощная машина, иначе этот глючный хипстерский кубернетис просто не развернётся, будет плеваться кучей ошибок абсолютно непонятного содержания. Ему, например, диски быстрые нужно, видите ли, иначе он обидится и не развернётся.

Ох уж эти сказочники.

Обычная машина, 2Gb RAM. 2 Core. Обычный диск, гигабайт на 10. Это достаточно для Master Node с Kubeadm.

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/

Точно работает, лично проверено.

Я не рекомендую это делать, так как Kubernetes master практически всегда идет бесплатно в предложениях Kubernetes PaaS.
Но, один раз нужно, для человека, который не придумывает ничего, не опробовав на собственном опыте. Чтобы без тени сомнения и с улыбкой полного превосходства разгонять Рабиновичей, перепевающих Паваротти.

S>2) ты должен вычистить с мащины всё: штатные докер вместе со всем его потрохами и зависимостями, раскиданными по всей системе, вычистить и firewall, иначае кубернетис им поперхнётся, отключить selinux. Чтоб вкорячить с кубернетесом именно ту версию докера, на которой ты тестил свой калстер. Если этого не сделать-получишь кучи ошибок абсолютно непонятного содержания
S>3) для развёртывания всего этого хозяйства нужно писать инстяллятор, это просто невозожно упаковать в rpm/deb.

Точно, Рабинович, в каждом звуке

S>А вот если не использовать докеры и кубернетесы, то достаточно использовать в проге компоненты из штатных реп и паковать прогу в deb/rpm. Тогда будет всё просто и красиво.

Здравствуйте, Sheridan, Вы писали:

S>Докер нужен всегда, везде и кубернетес пророк его -> глупость. Где докер имеет право на существование я уже писал

Автор: Sheridan
Дата: 07.05.20

.
S>Надо ложить на актуализацию используемых в проекте либ -> глупость. Либы в проекта должны быть свежими. Их актуализацию надо планировать. Даже в проектах, ушедших с разработки в саппорт.
S>Изоляция строго необходима -> глупость. Изоляция нужна при запуске опасных процессов, способных развалить систему. Например, при экспериментах с вирусами. Либо для ещё одного слоя усложнения доступа к важным данным из соседних процессов. Например, к персональным данным. В остальных случаях можно обойтись.

Защищённый режим процессора строго необходим — глупость. Изолированные адресные пространства нужны только при запуске опасных процессов, либо для ещё одного слоя усложнения доступа к важным данным из соседних процессов. В остальных случаях можно обойтись общим адресным пространством для всех процессов

Здравствуйте, smeeld, Вы писали:

S>Это не я, это пересказываю впечатления отдела внедрения. Мне с такими субстанциями возиться по долгу службы не довелось, слава богу.

Я бы это сам проверял, чтобы "перед пацанами" из-за такого "отдела" не подставляться

Хотя, все правильно сделали. Если не могут пройти простейший админский квест (в установке с kubeadm, просто работа с терминалом, ничего специфичного), то лучше сразу бежать и не тратить время.


И это одна из самых сложных установок, Я уж не говорю про простейшие случаи, типа K3S

curl -sfL https://get.k3s.io | sh —
# Check for Ready node,
takes maybe 30 seconds
k3s kubectl get node

Здравствуйте, L.K., Вы писали:

SVZ>>Вот пришел Шеридан и заактуализировал либу на работающем сервере вусмерть.
SVZ>>Как тестирование поможет?

LK>Очень просто. Шеридан сначала проверяет новую либу на тестовом серваке. Потом исправляет косяки своего кода, связанные с изменившейся либой.

Минуточку!
Давай определимся, откуда у Шеридана возьмется собственный код.
Если речь идёт о собственной локальной разработке, то железо, операционка, окружение, код — всё находится под контролем. Тогда докер и вправду не особо нужен.

А если это разработка на продажу, то у местного Шеридана будут только бинарники для установки. И если он чего-нить наменяет в окружении, то может случиться Ой.

SVZ>А если это разработка на продажу, то у местного Шеридана будут только бинарники для установки. И если он чего-нить наменяет в окружении, то может случиться Ой.

Да не только на продажу. Даже внутренние продукты (микро- и прочие сервисы).

Здравствуйте, smeeld, Вы писали:

s> C>У меня K8S работает на Raspberry Pi.

s> Хеллоуворлды где угодно запустятся

s> C>Ещё один воинствующий неумеха появился в теме.

s> Это не я, это пересказываю впечатления отдела внедрения. Мне с такими субстанциями возиться по долгу службы не довелось, слава богу.

Полный отдел Шериданов

Здравствуйте, Mystic Artifact, Вы писали:

S>>Извини если грубо. Причины описанной ситуации то понял?
MA> Я писал, что при изменении внешних зависимостей, мало что можно гарантировать, в случае, если они меняются вне зависимости от нас.
Смотри. Поменяться они могут только в двух случаях:
1. Либа обновилась на более новую версию
2. Либа откатилась на более старую версию.

Первое — нормальная жизнь, так и должно быть. Если вы отслеживаете и своевременно переходите тоже — всё ок.
Второе может случиться только тогда, когда ктото ленивый принесёт с собой старую версию и насильно впихнёт её в хост.

А я веду к тому, что чем меньше будет ленивых, тем реже будет встречаться авралы обоих типов.

Здравствуйте, Vetal_ca, Вы писали:

V_>

V_> curl -sfL https://get.k3s.io | sh —
V_> # Check for Ready node,
V_> takes maybe 30 seconds
V_> k3s kubectl get node

Здравствуйте, MuPoB, Вы писали:


Ты правильно понял направление моей мысли.

Здравствуйте, Vetal_ca, Вы писали:


V_>Чудовищно, это сколько? В процентах, с примерами, если не брать образы от новичков, где в базовый полный Ubuntu запихан

Я о том, что если войдет в моду каждую программу оборачивать в контейнер. Хотя может и переборщил с эпитетом.

Здравствуйте, Michael7, Вы писали:

V_>>Чудовищно, это сколько? В процентах, с примерами, если не брать образы от новичков, где в базовый полный Ubuntu запихан
M>Я о том, что если войдет в моду каждую программу оборачивать в контейнер. Хотя может и переборщил с эпитетом.
Ubuntu Snaps или Flatpak в Fedora — это так и есть. Каждая программа в контейнере.

На самом деле, подход очень неизбежный. Windows примерно так же работает сейчас с SxS-сборками и библиотеками, только там это делается с помощью магии в манифестах, а не chroot'ом.