O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

What's missing from upstream kernel containers?

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 8 Anúncio

What's missing from upstream kernel containers?

Baixar para ler offline

While we ported OpenVZ from RHEL6 (2.6.32) to RHEL7 (3.10) kernel, we discovered what pieces needed for OpenVZ are still missing from the upstream kernel.
Presented during Containers Microconference at Linux Plumbers 2015, Seattle.

While we ported OpenVZ from RHEL6 (2.6.32) to RHEL7 (3.10) kernel, we discovered what pieces needed for OpenVZ are still missing from the upstream kernel.
Presented during Containers Microconference at Linux Plumbers 2015, Seattle.

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (17)

Quem viu também gostou (17)

Anúncio

Semelhante a What's missing from upstream kernel containers? (20)

Mais recentes (20)

Anúncio

What's missing from upstream kernel containers?

  1. 1. Containers in the upstream kernel (as compared to VZ kernel) Containers in the upstream kernel (as compared to VZ kernel) Kir Kolyshkin, Sergey Bronnikov
  2. 2. Who we are?Who we are? • OpenVZ is an open source implementation of Linux containers • Kir Kolyshkin - leading OpenVZ for 10 years • Sergey Bronnikov - community manager of OpenVZ project
  3. 3. OpenVZ contribution to the Linux kernel:OpenVZ contribution to the Linux kernel: v2.6.13v2.6.16v2.6.19v2.6.22v2.6.25v2.6.28v2.6.31v2.6.34v2.6.37 v3.0 v3.3 v3.6 v3.9 v3.12 v3.15 v3.18 HEAD 0 100 200 300 400 2000+ commits
  4. 4. Is OpenVZ kernel upstreamed yet? ● Yes! ● About 60% ● Biggest pieces: – NET and PID namespaces – Memory cgroup, device cgroup – CRIU – NFS virtualization
  5. 5. Virtuozzo kernel changes (LOC)Virtuozzo kernel changes (LOC) RHEL5 (2.6.18) RHEL6 (2.6.32) RHEL7 (3.10) 0 70000 140000 210000 280000 264,641 202,746 66,324
  6. 6. Things we (still) need to add 1/2 ● Ploop and related ext4 changes ● Memory management and accounting – backport of kmemcg – idle memory tracking (for vcmmd) – network buffers memory accounting – OOM killer virtualization ● /sys and /proc virtualization
  7. 7. Things we (still) need to add 2/2 ● Network: venet, iptables (marks) ● FUSE upstream backports ● Printk virtualization ● /dev/console virtualization ● Time namespace (for monotonic timers wrt migration) ● Misc legacy (vziolimit, vzlist, vzredir, vznetstat, beancounters...) – Beancounters: numiptent, numfile, numproc
  8. 8. Any patches? Questions?Any patches? Questions? Kir Kolyshkin kir@openvz.org, @kolyshkin Sergey Bronnikov sergeyb@openvz.org, @estet

Notas do Editor

  • Зачем нам отдавать свои патчи в мейнстрим
    меньше усилий по поддержке своих патчей во время переезда на новую версию ядра
    хотим, чтобы нашими контейнерами можно было пользоваться без установки специального ядра
    FIXME: количество патчей для разных компонентов ядра 2.6.18 vs 2.6.32, 2.6.32 vs 3.11
    FIXME: добавить картинку с нашими патчами в upstream (http://openvz.org/File:Kernel_patches_stats.png)
    мы добавили:
    namespaces (pid, ipc, network)
    CRIU
    cgroups controllers
    нужен график коммитов в ядро http://openvz.org/File:Kernel_patches_stats.png
    У нас есть OpenVZ -- большой набор патчей, реализующих разную функциональность для контейнеров. Эта функциональность делится на некие "кирпичики", составляющие. Ну, например, network namespaces -- возможность иметь в ядре Линукса не одну сущность под названием "сетевая подсистема", а много. Эта сущность включает в себя экземпляр TCP/IP стека, таблицы маршрутизации, таблицы фаерволлинга, всякие разные кеши и хеши, ну и собственно сами сетевые устройства. Возможность создавать свои отдельные экземпляры сетевой подсистемы, отдавать его контейнеру, прокидывать туда устройства и т.п. -- это и есть один из "кирпичиков", из которых построена OpenVZ.
    Так вот, время от времени мы берём такой кирпичик и пытаемся воссоздать его в мейнстрим-ядре. Не просто послать на linux-kernel@ часть наших патчей, а именно воссоздать, то есть по сути с нуля, заново реализовать, представить на суд общественности, получить комментарии, поправить, представить на суд общественности -- и так далее, пока или оно не будет принято, или кончится терпение и мы плюнем на это неподъёмное дело. Вот таким примерно образом мы "засовываем" OpenVZ в мейнстрим ядро. После того, как "кирпичик" появляется в мейнстриме, мы выкидываем аналогичную часть из нашего патча и адаптируемся к мейнстримному (иногда написанному нами же, иногда нет).
    http://k001.livejournal.com/774225.html
    Отчего же тогда мы не отдаём весь ядерный код OpenVZ в ваниллу? Мы отдаём! Уже несколько лет как этим занимаемся, с переменным успехом (сейчас, я посмотрел, в ядре примерно 1700 патчей от нас, что не так уж и хреново, хотя, конечно, хочется много больше).
    Как это примерно происходит, описано выше на примере PID namespace. Бывает, что сложнее, бывает, что проще, бывает, что вообще не удаётся сделать то, что примут. Не потому, что криво, глючно и никому не надо, как думают аналитики на ЛОРе, а потому, что процесс принятия патчей -- сложный, по ряду причин. Например, мало кто понимает, что такое контейнеры и нафига они вообще нужны. Или понимают, но имеют своё, отличающееся от нашего видение, как решать ту или иную проблему. Поэтому тут больше надо разговаривать, убеждать, отстаивать свои подходы, чем просто писать и засылать хороший код. Для тех, кто думает, что на самом деле всё просто, а просто наши инженеры тупые -- покажите мне, сколько ваших нетривиальных патчей приняли, и мы поговорим.
    Что насчёт светлого будущего? Какое оно? Когда оно наступит? В нашем понимании, идеальное светлое будущее -- это когда OpenVZ патч к ядру будет нулевого размера, то есть мы хотим, чтобы вся функциональность, которая есть в OpenVZ, появилась в ванильном ядре. Когда это наступит? Я боюсь, что никогда, ибо мир неидеален. Но если, скажем, в ванилле будет 60 или 80% нашей функциональности -- я буду счастлив (сейчас там примерно 20-30%, точнее сложно сказать).
    http://ru-openvz.livejournal.com/1970.html
  • This slide show amount of patchset for three

×