docs/report/vpp_performance_tests/documentation/containers.rst

   1
   2 .. _container_orchestration_in_csit:
   3
   4 Container Orchestration in CSIT
   5 ===============================
   6
   7 Overview
   8 --------
   9
  10 Linux Containers
  11 ~~~~~~~~~~~~~~~~
  12
  13 Linux Containers is an OS-level virtualization method for running
  14 multiple isolated Linux systems (containers) on a compute host using a
  15 single Linux kernel. Containers rely on Linux kernel cgroups
  16 functionality for controlling usage of shared system resources (i.e.
  17 CPU, memory, block I/O, network) and for namespace isolation. The latter
  18 enables complete isolation of applications' view of operating
  19 environment, including process trees, networking, user IDs and mounted
  20 file systems.
  21
  22 :abbr:`LXC (Linux Containers)` combine kernel's cgroups and support for isolated
  23 namespaces to provide an isolated environment for applications. Docker
  24 does use LXC as one of its execution drivers, enabling image management
  25 and providing deployment services. More information in [lxc]_, [lxcnamespace]_
  26 and [stgraber]_.
  27
  28 Linux containers can be of two kinds: privileged containers and
  29 unprivileged containers.
  30
  31 Unprivileged Containers
  32 ~~~~~~~~~~~~~~~~~~~~~~~
  33
  34 Running unprivileged containers is the safest way to run containers in a
  35 production environment. From LXC 1.0 one can start a full system
  36 container entirely as a user, allowing to map a range of UIDs on the
  37 host into a namespace inside of which a user with UID 0 can exist again.
  38 In other words an unprivileged container does mask the userid from the
  39 host, making it impossible to gain a root access on the host even if a
  40 user gets root in a container. With unprivileged containers, non-root
  41 users can create containers and will appear in the container as the
  42 root, but will appear as userid <non-zero> on the host. Unprivileged
  43 containers are also better suited to supporting multi-tenancy operating
  44 environments. More information in [lxcsecurity]_ and [stgraber]_.
  45
  46 Privileged Containers
  47 ~~~~~~~~~~~~~~~~~~~~~
  48
  49 Privileged containers do not mask UIDs, and container UID 0 is mapped to
  50 the host UID 0. Security and isolation is controlled by a good
  51 configuration of cgroup access, extensive AppArmor profile preventing
  52 the known attacks as well as container capabilities and SELinux. Here a
  53 list of applicable security control mechanisms:
  54
  55 - Capabilities - keep (whitelist) or drop (blacklist) Linux capabilities,
  56   [capabilities]_.
  57 - Control groups - cgroups, resource bean counting, resource quotas, access
  58   restrictions, [cgroup1]_, [cgroup2]_.
  59 - AppArmor - apparmor profiles aim to prevent any of the known ways of
  60   escaping a container or cause harm to the host, [apparmor]_.
  61 - SELinux - Security Enhanced Linux is a Linux kernel security module
  62   that provides similar function to AppArmor, supporting access control
  63   security policies including United States Department of Defense–style
  64   mandatory access controls. Mandatory access controls allow an
  65   administrator of a system to define how applications and users can
  66   access different resources such as files, devices, networks and inter-
  67   process communication, [selinux]_.
  68 - Seccomp - secure computing mode, enables filtering of system calls,
  69   [seccomp]_.
  70
  71 More information in [lxcsecurity]_ and [lxcsecfeatures]_.
  72
  73 **Linux Containers in CSIT**
  74
  75 CSIT is using Privileged Containers as the ``sysfs`` is mounted with RW
  76 access. Sysfs is required to be mounted as RW due to VPP accessing
  77 :command:`/sys/bus/pci/drivers/uio_pci_generic/unbind`. This is not the case of
  78 unprivileged containers where ``sysfs`` is mounted as read-only.
  79
  80
  81 Orchestrating Container Lifecycle Events
  82 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  83
  84 Following Linux container lifecycle events need to be addressed by an
  85 orchestration system:
  86
  87 1. Acquire - acquiring/downloading existing container images via
  88    :command:`docker pull` or :command:`lxc-create -t download`.
  89
  90 2. Build - building a container image from scratch or another
  91    container image via :command:`docker build <dockerfile/composefile>` or
  92    customizing LXC templates in
  93    `GitHub <https://github.com/lxc/lxc/tree/master/templates>`_.
  94
  95 3. (Re-)Create - creating a running instance of a container application
  96    from anew, or re-creating one that failed. A.k.a. (re-)deploy via
  97    :command:`docker run` or :command:`lxc-start`
  98
  99 4. Execute - execute system operations within the container by attaching to
 100    running container. THis is done by :command:`lxc-attach` or
 101    :command:`docker exec`
 102
 103 5. Distribute - distributing pre-built container images to the compute
 104    nodes. Currently not implemented in CSIT.
 105
 106
 107 Container Orchestration Systems Used in CSIT
 108 --------------------------------------------
 109
 110 Current CSIT testing framework integrates following Linux container
 111 orchestration mechanisms:
 112
 113 - LXC/Docker for complete VPP container lifecycle control.
 114 - Combination of Kubernetes (container orchestration), Docker (container
 115   images) and Ligato (container networking).
 116
 117 LXC
 118 ~~~
 119
 120 LXC is the well-known and heavily tested low-level Linux container
 121 runtime [lxcsource]_, that provides a userspace interface for the Linux kernel
 122 containment features. With a powerful API and simple tools, LXC enables
 123 Linux users to easily create and manage system or application
 124 containers. LXC uses following kernel features to contain processes:
 125
 126 - Kernel namespaces: ipc, uts, mount, pid, network and user.
 127 - AppArmor and SELinux security profiles.
 128 - Seccomp policies.
 129 - Chroot.
 130 - Cgroups.
 131
 132 CSIT uses LXC runtime and LXC usertools to test VPP data plane performance in
 133 a range of virtual networking topologies.
 134
 135 **Known Issues**
 136
 137 - Current CSIT restriction: only single instance of lxc runtime due to
 138   the cgroup policies used in CSIT. There is plan to add the capability into
 139   code to create cgroups per container instance to address this issue. This sort
 140   of functionality is better supported in LXC 2.1 but can be done is current
 141   version as well.
 142
 143 - CSIT code is currently using cgroup to control the range of CPU cores the
 144   LXC container runs on. VPP thread pinning is defined vpp startup.conf.
 145
 146 Docker
 147 ~~~~~~
 148
 149 Docker builds on top of Linux kernel containment features, and
 150 offers a high-level tool for wrapping the processes, maintaining and
 151 executing them in containers [docker]_. Currently it using *runc* a CLI tool for
 152 spawning and running containers according to the `OCI specification
 153 <https://www.opencontainers.org/>`_
 154
 155 A Docker container image is a lightweight, stand-alone, executable
 156 package of a piece of software that includes everything needed to run
 157 it: code, runtime, system tools, system libraries, settings.
 158
 159 CSIT uses Docker to manage the maintenance and execution of
 160 containerized applications used in CSIT performance tests.
 161
 162 - Data plane thread pinning to CPU cores - Docker CLI and/or Docker
 163   configuration file controls the range of CPU cores the Docker image
 164   must run on. VPP thread pinning defined vpp startup.conf.
 165
 166 Kubernetes
 167 ~~~~~~~~~~
 168
 169 Kubernetes [k8sdoc]_, or K8s, is a production-grade container orchestration
 170 platform for automating the deployment, scaling and operating
 171 application containers. Kubernetes groups containers that make up an
 172 application into logical units, pods, for easy management and discovery.
 173 K8s pod definitions including compute resource allocation is provided in
 174 .yaml files.
 175
 176 CSIT uses K8s and its infrastructure components like etcd to control all
 177 phases of container based virtualized network topologies.
 178
 179 Ligato
 180 ~~~~~~
 181
 182 Ligato [ligato]_ is an open-source project developing a set of cloud-native
 183 tools for orchestrating container networking. Ligato integrates with FD.io VPP
 184 using goVPP [govpp]_ and vpp-agent [vppagent]_.
 185
 186 **Known Issues**
 187
 188 - Currently using a separate LF Jenkins job for building csit-centric
 189   prod_vpp_agent docker images vs. dockerhub/ligato ones.
 190
 191 Implementation
 192 --------------
 193
 194 CSIT container orchestration is implemented in CSIT Level-1 keyword
 195 Python libraries following the Builder design pattern. Builder design
 196 pattern separates the construction of a complex object from its
 197 representation, so that the same construction process can create
 198 different representations e.g. LXC, Docker, other.
 199
 200 CSIT Robot Framework keywords are then responsible for higher level
 201 lifecycle control of of the named container groups. One can have
 202 multiple named groups, with 1..N containers in a group performing
 203 different role/functionality e.g. NFs, Switch, Kafka bus, ETCD
 204 datastore, etc. ContainerManager class acts as a Director and uses
 205 ContainerEngine class that encapsulate container control.
 206
 207 Current CSIT implementation is illustrated using UML Class diagram:
 208
 209 1. Acquire
 210 2. Build
 211 3. (Re-)Create
 212 4. Execute
 213
 214 ::
 215
 216  +-----------------------------------------------------------------------+
 217  |              RF Keywords (high level lifecycle control)               |
 218  +-----------------------------------------------------------------------+
 219  | Construct VNF containers on all DUTs                                  |
 220  | Acquire all '${group}' containers                                     |
 221  | Create all '${group}' containers                                      |
 222  | Install all '${group}' containers                                     |
 223  | Configure all '${group}' containers                                   |
 224  | Stop all '${group}' containers                                        |
 225  | Destroy all '${group}' containers                                     |
 226  +-----------------+-----------------------------------------------------+
 227                    |  1
 228                    |
 229                    |  1..N
 230  +-----------------v-----------------+        +--------------------------+
 231  |          ContainerManager         |        |  ContainerEngine         |
 232  +-----------------------------------+        +--------------------------+
 233  | __init()__                        |        | __init(node)__           |
 234  | construct_container()             |        | acquire(force)           |
 235  | construct_containers()            |        | create()                 |
 236  | acquire_all_containers()          |        | stop()                   |
 237  | create_all_containers()           | 1    1 | destroy()                |
 238  | execute_on_container()            <>-------| info()                   |
 239  | execute_on_all_containers()       |        | execute(command)         |
 240  | install_vpp_in_all_containers()   |        | system_info()            |
 241  | configure_vpp_in_all_containers() |        | install_supervisor()     |
 242  | stop_all_containers()             |        | install_vpp()            |
 243  | destroy_all_containers()          |        | restart_vpp()            |
 244  +-----------------------------------+        | create_vpp_exec_config() |
 245                                               | create_vpp_startup_config|
 246                                               | is_container_running()   |
 247                                               | is_container_present()   |
 248                                               | _configure_cgroup()      |
 249                                               +-------------^------------+
 250                                                             |
 251                                                             |
 252                                                             |
 253                                                  +----------+---------+
 254                                                  |                    |
 255                                           +------+-------+     +------+-------+
 256                                           |     LXC      |     |    Docker    |
 257                                           +--------------+     +--------------+
 258                                           | (inherinted) |     | (inherinted) |
 259                                           +------+-------+     +------+-------+
 260                                                   |                   |
 261                                                   +---------+---------+
 262                                                             |
 263                                                             | constructs
 264                                                             |
 265                                                   +---------v---------+
 266                                                   |     Container     |
 267                                                   +-------------------+
 268                                                   | __getattr__(a)    |
 269                                                   | __setattr__(a, v) |
 270                                                   +-------------------+
 271
 272 Sequentional diagram that illustrates the creation of a single container.
 273
 274 ::
 275
 276  Legend:
 277     e  = engine [Docker|LXC]
 278     .. = kwargs (variable number of keyword argument)
 279
 280  +-------+                  +------------------+       +-----------------+
 281  | RF KW |                  | ContainerManager |       | ContainerEngine |
 282  +---+---+                  +--------+---------+       +--------+--------+
 283      |                               |                          |
 284      |  1: new ContainerManager(e)   |                          |
 285     +-+---------------------------->+-+                         |
 286     |-|                             |-| 2: new ContainerEngine  |
 287     |-|                             |-+----------------------->+-+
 288     |-|                             |-|                        |-|
 289     |-|                             +-+                        +-+
 290     |-|                              |                          |
 291     |-| 3: construct_container(..)   |                          |
 292     |-+---------------------------->+-+                         |
 293     |-|                             |-| 4: init()               |
 294     |-|                             |-+----------------------->+-+
 295     |-|                             |-|                        |-| 5: new  +-------------+
 296     |-|                             |-|                        |-+-------->| Container A |
 297     |-|                             |-|                        |-|         +-------------+
 298     |-|                             |-|<-----------------------+-|
 299     |-|                             +-+                        +-+
 300     |-|                              |                          |
 301     |-| 6: acquire_all_containers()  |                          |
 302     |-+---------------------------->+-+                         |
 303     |-|                             |-| 7: acquire()            |
 304     |-|                             |-+----------------------->+-+
 305     |-|                             |-|                        |-|
 306     |-|                             |-|                        |-+--+
 307     |-|                             |-|                        |-|  | 8: is_container_present()
 308     |-|                             |-|             True/False |-|<-+
 309     |-|                             |-|                        |-|
 310     |-|                             |-|                        |-|
 311  +---------------------------------------------------------------------------------------------+
 312  |  |-| ALT [isRunning & force]     |-|                        |-|--+                          |
 313  |  |-|                             |-|                        |-|  | 8a: destroy()            |
 314  |  |-|                             |-|                        |-<--+                          |
 315  +---------------------------------------------------------------------------------------------+
 316     |-|                             |-|                        |-|
 317     |-|                             +-+                        +-+
 318     |-|                              |                          |
 319     |-| 9: create_all_containers()   |                          |
 320     |-+---------------------------->+-+                         |
 321     |-|                             |-| 10: create()            |
 322     |-|                             |-+----------------------->+-+
 323     |-|                             |-|                        |-+--+
 324     |-|                             |-|                        |-|  | 11: wait('RUNNING')
 325     |-|                             |-|                        |-<--+
 326     |-|                             +-+                        +-+
 327     |-|                              |                          |
 328  +---------------------------------------------------------------------------------------------+
 329  |  |-| ALT                          |                          |                              |
 330  |  |-| (install_vpp, configure_vpp) |                          |                              |
 331  |  |-|                              |                          |                              |
 332  +---------------------------------------------------------------------------------------------+
 333     |-|                              |                          |
 334     |-| 12: destroy_all_containers() |                          |
 335     |-+---------------------------->+-+                         |
 336     |-|                             |-| 13: destroy()           |
 337     |-|                             |-+----------------------->+-+
 338     |-|                             |-|                        |-|
 339     |-|                             +-+                        +-+
 340     |-|                              |                          |
 341     +++                              |                          |
 342      |                               |                          |
 343      +                               +                          +
 344
 345 Container Data Structure
 346 ~~~~~~~~~~~~~~~~~~~~~~~~
 347
 348 Container is represented in Python L1 library as a separate Class with instance
 349 variables and no methods except overriden ``__getattr__`` and ``__setattr__``.
 350 Instance variables are assigned to container dynamically during the
 351 ``construct_container(**kwargs)`` call and are passed down from the RF keyword.
 352
 353 Usage example:
 354
 355 .. code-block:: robotframework
 356
 357   | Construct VNF containers on all DUTs
 358   | | [Arguments] | ${technology} | ${image} | ${cpu_count}=${1} | ${count}=${1}
 359   | | ...
 360   | | ${group}= | Set Variable | VNF
 361   | | ${skip_cpus}= | Evaluate | ${vpp_cpus}+${system_cpus}
 362   | | Import Library | resources.libraries.python.ContainerUtils.ContainerManager
 363   | | ... | engine=${container_engine} | WITH NAME | ${group}
 364   | | ${duts}= | Get Matches | ${nodes} | DUT*
 365   | | :FOR | ${dut} | IN | @{duts}
 366   | | | ${env}= | Create List | DEBIAN_FRONTEND=noninteractive
 367   | | | ${mnt}= | Create List | /tmp:/mnt/host | /dev:/dev
 368   | | | ${cpu_node}= | Get interfaces numa node | ${nodes['${dut}']}
 369   | | | ... | ${dut1_if1} | ${dut1_if2}
 370   | | | Run Keyword | ${group}.Construct containers
 371   | | | ... | name=${dut}_${group} | node=${nodes['${dut}']} | mnt=${mnt}
 372   | | | ... | image=${container_image} | cpu_count=${container_cpus}
 373   | | | ... | cpu_skip=${skip_cpus} | cpuset_mems=${cpu_node}
 374   | | | ... | cpu_shared=${False} | env=${env} | count=${container_count}
 375   | | | ... | install_dkms=${container_install_dkms}
 376   | | Append To List | ${container_groups} | ${group}
 377
 378 Mandatory parameters to create standalone container are: ``node``, ``name``,
 379 ``image`` [imagevar]_, ``cpu_count``, ``cpu_skip``, ``cpuset_mems``,
 380 ``cpu_shared``.
 381
 382 There is no parameters check functionality. Passing required arguments is in
 383 coder responsibility. All the above parameters are required to calculate the
 384 correct cpu placement. See documentation for the full reference.
 385
 386 Kubernetes
 387 ~~~~~~~~~~
 388
 389 Kubernetes is implemented as separate library ``KubernetesUtils.py``,
 390 with a class with the same name. This utility provides an API for L2
 391 Robot Keywords to control ``kubectl`` installed on each of DUTs. One
 392 time initialization script, ``resources/libraries/bash/k8s_setup.sh``
 393 does reset/init kubectl, applies Calico v2.6.3 and initializes the
 394 ``csit`` namespace. CSIT namespace is required to not to interfere with
 395 existing setups and it further simplifies apply/get/delete
 396 Pod/ConfigMap operations on SUTs.
 397
 398 Kubernetes utility is based on YAML templates to avoid crafting the huge
 399 YAML configuration files, what would lower the readability of code and
 400 requires complicated algorithms. The templates can be found in
 401 ``resources/templates/kubernetes`` and can be leveraged in the future
 402 for other separate tasks.
 403
 404 Two types of YAML templates are defined:
 405
 406 - Static - do not change between deployments, that is infrastructure
 407   containers like Kafka, Calico, ETCD.
 408
 409 - Dynamic - per test suite/case topology YAML files e.g. SFC_controller,
 410   VNF, VSWITCH.
 411
 412 Making own python wrapper library of ``kubectl`` instead of using the
 413 official Python package allows to control and deploy environment over
 414 the SSH library without the need of using isolated driver running on
 415 each of DUTs.
 416
 417 Ligato
 418 ~~~~~~
 419
 420 Ligato integration does require to compile the ``vpp-agent`` tool and build the
 421 bundled Docker image. Compilation of ``vpp-agent`` depends on specific VPP. In
 422 ``ligato/vpp-agent`` repository there are well prepared scripts for building the
 423 Docker image. Building docker image is possible via series of commands:
 424
 425 ::
 426
 427   git clone https://github.com/ligato/vpp-agent
 428   cd vpp_agent/docker/dev_vpp_agent
 429   sudo docker build -t dev_vpp_agent --build-arg AGENT_COMMIT=<agent commit id>\
 430       --build-arg VPP_COMMIT=<vpp commit id> --no-cache .
 431   sudo ./shrink.sh
 432   cd ../prod_vpp_agent
 433   sudo ./build.sh
 434   sudo ./shrink.sh
 435
 436 CSIT requires Docker image to include the desired VPP version (per patch
 437 testing, nightly testing, on demand testing).
 438
 439 The entire build process of building ``dev_vpp_agent`` image heavily depends
 440 on internet connectivity and also takes a significant amount of time (~1-1.5h
 441 based on internet bandwidth and allocated resources). The optimal solution would
 442 be to build the image on jenkins slave, transfer the Docker image to DUTs and
 443 execute separate suite of tests.
 444
 445 To adress the amount of time required to build ``dev_vpp_agent`` image, we can
 446 pull existing specific version of ```dev_vpp_agent``` and exctract the
 447 ```vpp-agent``` from it.
 448
 449 We created separate sets of Jenkins jobs, that will be executing following:
 450
 451 1. Clone latest CSIT and Ligato repositaries.
 452 2. Pull specific version of ``dev_vpp_agent`` image from Dockerhub.
 453 3. Extract VPP API (from ``.deb`` package) and copy into ``dev_vpp_agent``
 454    image
 455 4. Rebuild vpp-agent and extract outside image.
 456 5. Build ``prod_vpp_image`` Docker image from ``dev_vpp_agent`` image.
 457 6. Transfer ``prod_vpp_agent`` image to DUTs.
 458 7. Execute subset of performance tests designed for Ligato testing.
 459
 460 ::
 461
 462  +-----------------------------------------------+
 463  |                  ubuntu:16.04                 <-----| Base image on Dockerhub
 464  +------------------------^----------------------+
 465                           |
 466                           |
 467  +------------------------+----------------------+
 468  |               ligato/dev_vpp_agent            <------| Pull this image from
 469  +------------------------^----------------------+      | Dockerhub ligato/dev_vpp_agent:<version>
 470                           |
 471                           | Rebuild and extract agent.tar.gz from dev_vpp_agent
 472  +------------------------+----------------------+
 473  |                 prod_vpp_agent                <------| Build by passing own
 474  +-----------------------------------------------+      | vpp.tar.gz (from nexus
 475                                                         | or built by JJB) and
 476                                                         | agent.tar.gz extracted
 477                                                         | from ligato/dev_vpp_agent
 478
 479
 480 Approximate size of vnf-agent docker images:
 481
 482 ::
 483
 484   REPOSITORY            TAG       IMAGE ID        CREATED        SIZE
 485   dev-vpp-agent         latest    78c53bd57e2     6 weeks ago    9.79GB
 486   prod_vpp_agent        latest    f68af5afe601    5 weeks ago    443MB
 487
 488 In CSIT we need to create separate performance suite under
 489 ``tests/kubernetes/perf`` which contains modified Suite setup in comparison
 490 to standard perf tests. This is due to reason that VPP will act as vswitch in
 491 Docker image and not as standalone installed service.
 492
 493 Tested Topologies
 494 ~~~~~~~~~~~~~~~~~
 495
 496 Listed CSIT container networking test topologies are defined with DUT
 497 containerized VPP switch forwarding packets between NF containers. Each
 498 NF container runs their own instance of VPP in L2XC configuration.
 499
 500 Following container networking topologies are tested in |csit-release|:
 501
 502 - LXC topologies:
 503
 504   - eth-l2xcbase-eth-2memif-1lxc.
 505   - eth-l2bdbasemaclrn-eth-2memif-1lxc.
 506
 507 - Docker topologies:
 508
 509   - eth-l2xcbase-eth-2memif-1docker.
 510   - eth-l2xcbase-eth-1memif-1docker
 511
 512 - Kubernetes/Ligato topologies:
 513
 514   - eth-1drcl2bdbasemaclrn-eth-2memif-1drcl2xc-1paral
 515   - eth-1drcl2bdbasemaclrn-eth-2memif-2drcl2xc-1horiz
 516   - eth-1drcl2bdbasemaclrn-eth-2memif-4drcl2xc-1horiz
 517   - eth-1drcl2bdbasemaclrn-eth-4memif-2drcl2xc-1chain
 518   - eth-1drcl2bdbasemaclrn-eth-8memif-4drcl2xc-1chain
 519   - eth-1drcl2xcbase-eth-2memif-1drcl2xc-1paral
 520   - eth-1drcl2xcbase-eth-2memif-2drcl2xc-1horiz
 521   - eth-1drcl2xcbase-eth-2memif-4drcl2xc-1horiz
 522   - eth-1drcl2xcbase-eth-4memif-2drcl2xc-1chain
 523   - eth-1drcl2xcbase-eth-8memif-4drcl2xc-1chain
 524
 525 References
 526 ~~~~~~~~~~
 527
 528 .. [lxc] `Linux Containers <https://linuxcontainers.org/>`_
 529 .. [lxcnamespace] `Resource management: Linux kernel Namespaces and cgroups <https://www.cs.ucsb.edu/~rich/class/cs293b-cloud/papers/lxc-namespace.pdf>`_.
 530 .. [stgraber] `LXC 1.0: Blog post series <https://stgraber.org/2013/12/20/lxc-1-0-blog-post-series/>`_.
 531 .. [lxcsecurity] `Linux Containers Security <https://linuxcontainers.org/lxc/security/>`_.
 532 .. [capabilities] `Linux manual - capabilities - overview of Linux capabilities <http://man7.org/linux/man-pages/man7/capabilities.7.html>`_.
 533 .. [cgroup1] `Linux kernel documentation: cgroups <https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt>`_.
 534 .. [cgroup2] `Linux kernel documentation: Control Group v2 <https://www.kernel.org/doc/Documentation/cgroup-v2.txt>`_.
 535 .. [selinux] `SELinux Project Wiki <http://selinuxproject.org/page/Main_Page>`_.
 536 .. [lxcsecfeatures] `LXC 1.0: Security features <https://stgraber.org/2014/01/01/lxc-1-0-security-features/>`_.
 537 .. [lxcsource] `Linux Containers source <https://github.com/lxc/lxc>`_.
 538 .. [apparmor] `Ubuntu AppArmor <https://wiki.ubuntu.com/AppArmor>`_.
 539 .. [seccomp] `SECure COMPuting with filters <https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt>`_.
 540 .. [docker] `Docker <https://www.docker.com/what-docker>`_.
 541 .. [k8sdoc] `Kubernetes documentation <https://kubernetes.io/docs/home/>`_.
 542 .. [ligato] `Ligato <https://github.com/ligato>`_.
 543 .. [govpp] `FD.io goVPP project <https://wiki.fd.io/view/GoVPP>`_.
 544 .. [vppagent] `Ligato vpp-agent <https://github.com/ligato/vpp-agent>`_.
 545 .. [imagevar] Image parameter is required in initial commit version. There is plan to implement container build class to build Docker/LXC image.