Архитектура контейнеров, часть 1. Почему важно понимать разницу между пространством пользователя и пространством ядра
Вам поручили спроектировать инфраструктуру на основе контейнеров? И вы, скорее всего, понимаете, какую пользу могут принести контейнеры разработчикам, архитекторам и командам эксплуатации. Вы уже что-то читали о них и с нетерпением ждете возможности более подробно изучить эту технологию. Однако перед погружением в обсуждение архитектуры и развертывание контейнеров в продакшн-окружении необходимо знать три важные вещи:
Все приложения, включая контейнерные, используют ядро базовой ОС.
Ядро предоставляет приложениям API через системные вызовы (system calls).
Важны версии этого API, так как это «клей», который обеспечивает детерминированное взаимодействие между пространством пользователя (user space) и пространством ядра (kernel space).
Иногда контейнеры рассматриваются как виртуальные машины, но важно отметить, что, в отличие от виртуальных машин, ядро является единственным слоем абстракции между программами и ресурсами, к которым необходим доступ. Давайте посмотрим почему.
Все процессы выполняют системные вызовы (system calls):
А поскольку контейнеры тоже являются процессами, они также выполняют системные вызовы:
Итак, у нас есть понимание, что такое процесс, и что контейнеры — это тоже процессы. Но что насчет файлов и программ, находящихся внутри контейнера? Эти файлы и программы находятся в так называемом пользовательском пространстве (user space). При старте контейнера в память загружается программа из образа контейнера. Но программе, запущенной в контейнере, по-прежнему необходимо выполнять системные вызовы в пространстве ядра (kernel space). Важна возможность детерминированного взаимодействия пользовательского пространства и пространства ядра.
Пользовательское пространство
Под пользовательским пространством понимается весь код операционной системы, который находится вне ядра. Большинство Unix-подобных операционных систем (включая Linux) поставляются с разнообразными предустановленными утилитами, средствами разработки и графическими инструментами — это все приложения пространства пользователя.
Приложения могут быть написаны на C, Java, Python, Ruby и других языках программирования. В мире контейнеров эти программы обычно поставляются в формате образа контейнера, такого как Docker. Когда вы запускаете в контейнере образ Red Hat Enterprise Linux 7 из Red Hat Registry, то используете предварительно настроенное минимальное пользовательское пространство Red Hat Enterprise Linux 7, содержащее такие утилиты, как bash, awk, grep и yum (для возможности установки дополнительного программного обеспечения).
docker run -i -t rhel7 bash
Все пользовательские приложения (и контейнеризированные и нет) при работе используют различные данные, но где эти данные хранятся? Какие-то данные поступают из регистров процессора и внешних устройств, но чаще они хранятся в памяти и на диске. Приложения получают доступ к данным, выполняя специальные запросы к ядру — системные вызовы. Например, такие как выделение памяти (для переменных) или открытие файла. В памяти и файлах часто хранится конфиденциальная информация, принадлежащая разным пользователям, поэтому доступ к ним должен запрашиваться у ядра с помощью системных вызовов.
Пространство ядра
Ядро обеспечивает абстракцию для безопасности, оборудования и внутренних структур данных. Например, системный вызов open() используется для получения дескриптора файла в Python, C, Ruby и других языках программирования. Вряд ли бы вы хотели, чтобы ваша программа работала с XFS на уровне битов, поэтому ядро предоставляет системные вызовы и работает с драйверами. Фактически этот системный вызов настолько распространен, что является частью библиотеки POSIX .
На следующем рисунке обратите внимание, что bash выполняет вызов getpid() , который возвращает его собственный идентификатор процесса. А команда cat запрашивает доступ к /etc/hosts с помощью вызова файла open() . В следующей статье мы рассмотрим, как это работает в мире контейнеров, а пока обратите внимание, что часть кода находится в пользовательском пространстве, а часть — в ядре.
Обычные программы пользовательского пространства для выполнения работы постоянно выполняют системные вызовы, например:
Некоторые программы, выполняемые в пользовательском пространстве, почти напрямую отображаются на системные вызовы, например:
Копнув на один уровень глубже, можно привести примеры системных вызовов, которые выполняются перечисленными выше программами. Обычно они вызываются через такие библиотеки, как glibc , или через интерпретатор (Ruby, Python) или через Java Virtual Machine.
Типичная программа получает доступ к ресурсам ядра через несколько слоев абстракции, как показано на следующем рисунке:
Чтобы получить представление о том, какие системные вызовы доступны в ядре Linux, смотрите man-страницу syscalls . Интересно заметить, что я запускаю эту команду на своем ноутбуке с Red Hat Enterprise Linux 7, но использую контейнер Red Hat Enterprise Linux 6, чтобы посмотреть, какие были изменения в системных вызовах:
Обратите внимание, что по информации из man какие-то системные вызовы (также известные как интерфейсы) были убраны, а какие-то добавлены. Линус Торвальдс и другие уделяют большое внимание тому, чтобы поведение системных вызовов было понятным и стабильным. В Red Hat Enterprise Linux 7 (ядро 3.10) доступно 382 системных вызова. Время от времени добавляются новые, а некоторые объявляются устаревшими. Это следует учитывать при рассмотрении жизненного цикла вашей контейнерной инфраструктуры и приложений, которые будут в ней работать.
Заключение
Есть несколько важных моментов, которые нужно знать про пользовательское пространство и пространство ядра:
Приложения содержат бизнес-логику, но используют системные вызовы.
После компиляции программы набор используемых системных вызовов встраивается в бинарный файл (в языках более высокого уровня это интерпретатор или JVM).
Контейнеры не абстрагируют (не отменяют) необходимость того, чтобы пользовательское пространство и пространство ядра использовали одинаковый набор системных вызовов.
В мире контейнеров пользовательское пространство упаковывается (bundle) и развертывается на различных хостах от ноутбуков до продуктивных серверов.
В ближайшие годы могут появиться проблемы.
Со временем будет сложно гарантировать, что контейнер, созданный сегодня, будет работать завтра. Представьте, что наступил 2024 год (возможно, наконец-то появятся настоящие ховерборды), а у вас все еще работает контейнеризованное приложение в проде для которого требуется пользовательское пространство Red Hat Enterprise Linux 7. Как безопасно обновить хост с контейнерами и инфраструктуру? Будет ли контейнеризированное приложение одинаково хорошо работать на новых хостах, доступных на рынке?
Во второй части этой серии (оригинал на англ. Architecting Containers Part 2: Why the User Space Matters) мы рассмотрим, как взаимосвязь между пространством пользователя и пространством ядра влияет на архитектурные решения и что можно сделать, чтобы минимизировать проблемы.
Перевод материала подготовлен в рамках курса «Administrator Linux. Professional». Всех желающих приглашаем на открытый урок «Использование VPN туннелей в Linux».
В ходе этого вебинара:
— узнаем, что такое VPN;
— познакомимся с основными видами VPN и сравним их;
— разберем варианты конфигурации OpenVPN, попробуем понять разницу между ними;
— познакомимся с WireGuard, сравним его производительность с OpenVPN.
Источник
Architecting Containers Part 1: Why Understanding User Space vs. Kernel Space Matters
Perhaps you’ve been charged with developing a container-based application infrastructure? If so, you most likely understand the value that containers can provide to your developers, architects, and operations team. In fact, you’ve likely been reading up on containers and are excited about exploring the technology in more detail. However, before diving head-first into a discussion about the architecture and deployment of containers in a production environment, there are three important things that developers, architects, and systems administrators, need to know:
- All applications, inclusive of containerized applications, rely on the underlying kernel
- The kernel provides an API to these applications via system calls
- Versioning of this API matters as it’s the «glue» that ensures deterministic communication between the user space and kernel space
While containers are sometimes treated like virtual machines, it is important to note, unlike virtual machines, the kernel is the only layer of abstraction between programs and the resources they need access to. Let’s see why.
All processes make system calls:
As containers are processes, they also make system calls:
OK, so you understand what a process is, and that containers are processes, but what about the files and programs that live inside a container image? These files and programs make up what is known as user space. When a container is started, a program is loaded into memory from the container image. Once the program in the container is running, it still needs to make system calls into kernel space. The ability for the user space and kernel space to communicate in a deterministic fashion is critical.
User Space
User space refers to all of the code in an operating system that lives outside of the kernel. Most Unix-like operating systems (including Linux) come pre-packaged with all kinds of utilities, programming languages, and graphical tools — these are user space applications. We often refer to this as «userland.»
Userland applications can include programs that are written in C, Java, Python, Ruby, and other languages. In a containerized world, these programs are typically delivered in a container image format such as Docker. When you pull down and run a Red Hat Enterprise Linux 7 container image from the Red Hat Registry, you are utilizing a pre-packaged, minimal Red Hat Enterprise Linux 7 user space which contains utilities such as bash, awk, grep, and yum (so that you can install other software).
All user programs (containerized or not) function by manipulating data, but where does this data live? This data can come from registers in the CPU and external devices, but most commonly it is stored in memory and on disk. User programs get access to data by making special requests to the kernel called system calls. Examples include allocating memory (variables) or opening a file. Memory and files often store sensitive information owned by different users, so access must be requested from the kernel through system calls.
Kernel Space
The kernel provides abstraction for security, hardware, and internal data structures. The open() system call is commonly used to get a file handle in Python, C, Ruby and other languages. You wouldn’t want your program to be able to make bit level changes to an XFS file system, so the kernel provides a system call and handles the drivers. In fact, this system call is so common that is part of the POSIX library.
Notice in the following drawing that bash makes a getpid() call which requests its own process identity. Also, notice that the cat command requests access to /etc/hosts with a file open() call. In the next article, we will dig into how this works in a containerized world, but notice that some code lives in user space, and some lives in the kernel.
Regular user space programs evoke system calls all the time to get work done, for example:
These are some user space programs that map almost directly to system calls, for example:
Digging one layer deeper, the following are some example system calls which are invoked by the above listed programs. Typically these functions are called through libraries such as glibc, or through an interpreter such as Ruby, Python, or the Java Virtual Machine.
A typical program gets access to resources in the kernel through layers of abstraction similar to the following diagram:
To get a feel for what system calls are available in a Linux kernel, check out the syscalls man page. Interestingly, I am invoking this command on my Red Hat Enterprise Linux 7 laptop, but I am using a Red Hat Enterprise Linux 6 container image (aka user space) because I want to see system calls which were added/removed in the older kernel:
Notice from the man page, that certain system calls (aka interfaces) have been added and removed in different versions of the kernel. Linus Torvalds et. al. take great care to keep the behavior of these system calls well understood and stable. As of Red Hat Enterprise Linux 7 (kernel 3.10), there are 382 syscalls available. From time to time new system calls are added, and old system calls are deprecated; this should be considered when thinking about the lifecycle of your container infrastructure and the applications that will run within it.
Conclusion
There are some important take aways that you need to understand about the user space and kernel space:
- Applications contain business logic, but rely on system calls.
- Once an application is compiled, the set of system calls that an application uses (i.e. relies upon) is embedded in the binary (in higher level languages, this is the interpreter or JVM).
- Containers don’t abstract the need for the user space and kernel space to share a common set of system calls.
- In a containerized world, this user space is bundled up and shipped around to different hosts, ranging from laptops to production servers.
- Over the coming years, this will create challenges.
Over time, it will be challenging to guarantee that a container built today will run on the container hosts of tomorrow. Imagine the year is 2024 (maybe we’ll finally have real hoverboards) and you still have a container-based application that requires a Red Hat Enterprise Linux 7 user space running in production. How can you safely upgrade the underlying container host and infrastructure? Will the containerized application run equally well on any of the latest greatest container hosts available in the market place?
In Architecting Containers Part 2: Why the User Space Matters, we will explore how the user space / kernel space relationship affects architectural decisions and what you can do to minimize these challenges.
Источник
