Long-Term Supported Versions

    Innovation Versions

      Interconnecting iSula with the shim v2 Secure Container

      Overview

      shim v2 is a next-generation shim solution. Compared with shim v1, shim v2 features shorter call chains, clearer architecture, and lower memory overhead in multi-service container scenarios. iSula can run secure containers through isulad-shim or containerd-shim-kata-v2. The isulad-shim component is the implementation of the shim v1 solution, and the containerd-shim-kata-v2 component is the implementation of the shim v2 solution in the secure container scenario. This document describes how to interconnect iSula with containerd-shim-kata-v2.

      Interconnecting with containerd-shim-kata-v2

      Prerequisites

      Before interconnecting iSula with containerd-shim-kata-v2, ensure that the following prerequisites are met:

      • iSulad and kata-containers have been installed.
      • StratoVirt supports only the devicemapper storage driver. Therefore, you need to configure the devicemapper environment and ensure that the devicemapper storage driver used by iSulad works properly.

      Environment Setup

      The following describes how to install and configure iSulad and kata-containers.

      Installing Dependencies

      Configure the Yum source based on the OS version and install iSulad and kata-containers as the root user.

      yum install iSulad
      yum install kata-containers
      

      Creating and Configuring a Storage Device

      Prepare a drive, for example, /dev/sdx. The drive will be formatted. This section uses the block device /dev/sda as an example.

      I. Creating devicemapper

      1. Create a physical volume (PV).

        $ pvcreate /dev/sda
          Physical volume "/dev/loop0" successfully created.
        
      2. Create a volume group (VG).

        $ vgcreate isula /dev/sda
          Volume group "isula" successfully created
        
      3. Create the logical volumes thinpool and thinpoolmeta.

        $ lvcreate --wipesignatures y -n thinpool isula -l 95%VG
          Logical volume "thinpool" created.
        
        $ lvcreate --wipesignatures y -n thinpoolmeta isula -l 1%VG
          Logical volume "thinpoolmeta" created.
        
      4. Convert the created logical volumes to a thin pool.

        $ lvconvert -y --zero n -c 64K \
        --thinpool isula/thinpool \
        --poolmetadata isula/thinpoolmeta
          Thin pool volume with chunk size 512.00 KiB can address at most 126.50 TiB of data.
          WARNING: Converting isula/thinpool and isula/thinpoolmeta to thin pool's data and metadata volumes with metadata wiping.
          THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
          Converted isula/thinpool and isula/thinpoolmeta to thin pool.
        
      5. Configure automatic extension of the thin pool using lvm.

        $ touch /etc/lvm/profile/isula-thinpool.profile
        $ cat << EOF > /etc/lvm/profile/isula-thinpool.profile
        activation {
          thin_pool_autoextend_threshold=80
          thin_pool_autoextend_percent=20
        }
        EOF
        $ lvchange --metadataprofile isula-thinpool isula/thinpool
        Logical volume isula/thinpool changed.
        

      II. Changing the iSulad Storage Driver Type and Setting the Default Runtime

      Modify the /etc/isulad/daemon.json configuration file. Set default-runtime to io.containerd.kata.v2 and storage-driver to devicemapper. The modification result is as follows:

       {
          "default-runtime": "io.containerd.kata.v2",
          "storage-driver": "devicemapper",
          "storage-opts": [
              "dm.thinpooldev=/dev/mapper/isula-thinpool",
              "dm.fs=ext4",
              "dm.min_free_space=10%"
          ],
      }
      

      III. Making the Configuration Take Effect

      1. Restart the iSulad for the configuration to take effect.

        # systemctl daemon-reload
        # systemctl restart isulad
        
      2. Check whether the iSula storage driver is successfully configured.

        # isula info
        

        If the following information is displayed, the configuration is successful:

        Storage Driver: devicemapper
        

      Interconnection Guide

      This section describes how to interconnect iSula with containerd-shim-kata-v2.

      By default, containerd-shim-kata-v2 uses QEMU as the virtualization component. The following describes how to configure QEMU and StratoVirt.

      Using QEMU

      If containerd-shim-kata-v2 uses QEMU as the virtualization component, perform the following operations to interconnect iSula with containerd-shim-kata-v2:

      1. Modify the kata configuration file /usr/share/defaults/kata-containers/configuration.toml.

        Set sandbox_cgroup_with_emulator to false. Currently, shim v2 does not support this function. Other parameters are the same as the kata configuration parameters in shim v1 or use the default values.

        sandbox_cgroup_with_emulator = false
        
      2. Use the BusyBox image to run the secure container and check whether the used runtime is io.containerd.kata.v2.

        $ id=`isula run -tid busybox /bin/sh`
        $ isula inspect -f '{{ json .HostConfig.Runtime }}' $id
        "io.containerd.kata.v2"
        
      3. Verify that the QEMU-based VM process is started. If it is started, QEMU is successfully interconnected with the shim v2 secure container.

        ps -ef | grep qemu
        

      Using StratoVirt

      If containerd-shim-kata-v2 uses StratoVirt as the virtualization component, perform the following operations to interconnect iSula with containerd-shim-kata-v2:

      1. Create the stratovirt.sh script in any directory (for example, /home) and add the execute permission to the file as the root user.

        # touch /home/stratovirt.sh
        # chmod +x /home/stratovirt.sh
        

        The content of stratovirt.sh is as follows, which is used to specify the path of StratoVirt:

        #!/bin/bash
        export STRATOVIRT_LOG_LEVEL=info  # set log level which includes trace, debug, info, warn and error.
        /usr/bin/stratovirt $@
        
      2. Modify the kata configuration file. Set hypervisor of the secure container to stratovirt, kernel to the absolute path of the StratoVirt kernel image, and initrd to the initrd image file of kata-containers (if you use YUM to install kata-containers, the initrd image file is downloaded by default and stored in the /var/lib/kata/ directory). StratoVirt supports only the devicemapper storage mode, prepare the environment in advance and set iSulad to the devicemapper mode.

        The configurations are as follows:

        [hypervisor.stratovirt]
        path = "/home/stratovirt.sh"
        kernel = "/var/lib/kata/vmlinux.bin"
        initrd = "/var/lib/kata/kata-containers-initrd.img"
        block_device_driver = "virtio-mmio"
        use_vsock = true
        enable_netmon = true
        internetworking_model="tcfilter"
        sandbox_cgroup_with_emulator = false
        disable_new_netns = false
        disable_block_device_use = false
        disable_vhost_net = true
        

        To use the vsock function in StratoVirt, enable the vhost_vsock kernel module and check whether the module is successfully enabled.

        modprobe vhost_vsock
        lsmod |grep vhost_vsock
        

        Download the kernel of the required version and architecture and save it to the /var/lib/kata/ directory. For example, download the openeuler repo of the x86 architecture of openEuler 21.03.

        cd /var/lib/kata
        wget https://repo.openeuler.org/openEuler-21.03/stratovirt_img/x86_64/vmlinux.bin
        
      3. Use the BusyBox image to run the secure container and check whether the used runtime is io.containerd.kata.v2.

        $ id=`isula run -tid busybox sh`
        $ isula inspect -f '{{ json .HostConfig.Runtime }}' $id
        "io.containerd.kata.v2"
        
      4. Verify that the StratoVirt-based VM process is started. If it is started, StratoVirt is successfully interconnected with the shim v2 secure container.

        ps -ef | grep stratovirt
        

      Bug Catching

      Buggy Content

      Bug Description

      Submit As Issue

      It's a little complicated....

      I'd like to ask someone.

      PR

      Just a small problem.

      I can fix it online!

      Bug Type
      Specifications and Common Mistakes

      ● Misspellings or punctuation mistakes;

      ● Incorrect links, empty cells, or wrong formats;

      ● Chinese characters in English context;

      ● Minor inconsistencies between the UI and descriptions;

      ● Low writing fluency that does not affect understanding;

      ● Incorrect version numbers, including software package names and version numbers on the UI.

      Usability

      ● Incorrect or missing key steps;

      ● Missing prerequisites or precautions;

      ● Ambiguous figures, tables, or texts;

      ● Unclear logic, such as missing classifications, items, and steps.

      Correctness

      ● Technical principles, function descriptions, or specifications inconsistent with those of the software;

      ● Incorrect schematic or architecture diagrams;

      ● Incorrect commands or command parameters;

      ● Incorrect code;

      ● Commands inconsistent with the functions;

      ● Wrong screenshots.

      Risk Warnings

      ● Lack of risk warnings for operations that may damage the system or important data.

      Content Compliance

      ● Contents that may violate applicable laws and regulations or geo-cultural context-sensitive words and expressions;

      ● Copyright infringement.

      How satisfied are you with this document

      Not satisfied at all
      Very satisfied
      Submit
      Click to create an issue. An issue template will be automatically generated based on your feedback.
      Bug Catching
      编组 3备份