Kata コンテナの簡単な概要とセットアップ

Kata コンテナの簡単な概要とセットアップ
この記事ではその仕組みについて説明します カタコンテナ、Docker との接続に関する実践的な部分もあります。

Docker に関する一般的な問題とその解決策について 書かれた, 今日はKata Containersからの実装について簡単に説明します。 Kata Containers は、軽量の仮想マシンに基づく安全なコンテナ ランタイムです。 これらのコンテナの操作は他のコンテナの場合と同じですが、さらにハードウェア仮想化テクノロジを使用してより信頼性の高い分離が行われます。 このプロジェクトは 2017 年に始まり、同名のコミュニティが Intel Clear Containers と Hyper.sh RunV からの最高のアイデアの統合を完了しました。その後、AMD64、ARM、IBM p-、z などのさまざまなアーキテクチャのサポートに向けた作業が続けられました。 -シリーズ。 さらに、ハイパーバイザー QEMU、Firecracker 内での作業がサポートされており、containerd との統合もあります。 コードは次の場所で入手できます。 GitHubの MITライセンスの下で。

主な機能

  • 別のコアを使用してネットワーク、メモリ、I/O を分離し、仮想化拡張機能に基づいてハードウェア分離を強制的に使用することができます。
  • OCI (コンテナ形式)、Kubernetes CRI などの業界標準のサポート
  • 通常の Linux コンテナの一貫したパフォーマンス、通常の VM のパフォーマンス オーバーヘッドなしで分離性を強化
  • 本格的な仮想マシン内でコンテナを実行する必要がなくなり、汎用インターフェイスにより統合と起動が簡素化されます。

インストール

あり 多くの インストール オプションについては、Centos 7 オペレーティング システムに基づいてリポジトリからインストールすることを検討します。
それが重要だ: Kata コンテナの動作はハードウェア上でのみサポートされており、仮想化転送は常に機能するとは限りません。 SSE4.1のサポートが必要 プロセッサーから。

Kata コンテナのインストールは非常に簡単です。

リポジトリを操作するためのユーティリティをインストールします。

# yum -y install yum-utils

Selinux を無効にします (設定する方が正しいですが、簡単にするために無効にします)。

# setenforce 0
# sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

リポジトリに接続してインストールを実行します

# source /etc/os-release
# ARCH=$(arch)
# BRANCH="${BRANCH:-stable-1.10}"
# yum-config-manager --add-repo "http://download.opensuse.org/repositories/home:/katacontainers:/releases:/${ARCH}:/${BRANCH}/CentOS_${VERSION_ID}/home:katacontainers:releases:${ARCH}:${BRANCH}.repo"
# yum -y install kata-runtime kata-proxy kata-shim

調整

docker を使用するようにセットアップします。そのインストールは一般的なものなので、これ以上詳しくは説明しません。

# rpm -qa | grep docker
docker-ce-cli-19.03.6-3.el7.x86_64
docker-ce-19.03.6-3.el7.x86_64
# docker -v
Docker version 19.03.6, build 369ce74a3c

daemon.json に変更を加えます。

# cat <<EOF > /etc/docker/daemon.json
{
  "default-runtime": "kata-runtime",
  "runtimes": {
    "kata-runtime": {
      "path": "/usr/bin/kata-runtime"
    }
  }
}
EOF

ドッカーを再起動します。

# service docker restart

機能テスト

docker を再起動する前にコンテナを起動すると、uname によってメイン システムで実行されているカーネルのバージョンが得られることがわかります。

# docker run busybox uname -a
Linux 19efd7188d06 3.10.0-1062.12.1.el7.x86_64 #1 SMP Tue Feb 4 23:02:59 UTC 2020 x86_64 GNU/Linux

再起動後、カーネルのバージョンは次のようになります。

# docker run busybox uname -a
Linux 9dd1f30fe9d4 4.19.86-5.container #1 SMP Sat Feb 22 01:53:14 UTC 2020 x86_64 GNU/Linux

もっとチームを!

# time docker run busybox mount
kataShared on / type 9p (rw,dirsync,nodev,relatime,mmap,access=client,trans=virtio)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,relatime,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (ro,nosuid,nodev,noexec,relatime,xattr,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (ro,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (ro,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/perf_event type cgroup (ro,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (ro,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/freezer type cgroup (ro,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
kataShared on /etc/resolv.conf type 9p (rw,dirsync,nodev,relatime,mmap,access=client,trans=virtio)
kataShared on /etc/hostname type 9p (rw,dirsync,nodev,relatime,mmap,access=client,trans=virtio)
kataShared on /etc/hosts type 9p (rw,dirsync,nodev,relatime,mmap,access=client,trans=virtio)
proc on /proc/bus type proc (ro,relatime)
proc on /proc/fs type proc (ro,relatime)
proc on /proc/irq type proc (ro,relatime)
proc on /proc/sys type proc (ro,relatime)
tmpfs on /proc/acpi type tmpfs (ro,relatime)
tmpfs on /proc/timer_list type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /sys/firmware type tmpfs (ro,relatime)

real    0m2.381s
user    0m0.066s
sys 0m0.039s

# time docker run busybox free -m
              total        used        free      shared  buff/cache   available
Mem:           1993          30        1962           0           1        1946
Swap:             0           0           0

real    0m3.297s
user    0m0.086s
sys 0m0.050s

高速負荷テスト

仮想化による損失を評価するには、主な例として sysbench を実行します。 この選択肢を取る.

Docker+containerdを使用してsysbenchを実行する

プロセッサテスト

sysbench 1.0:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time

Prime numbers limit: 20000

Initializing worker threads...

Threads started!

General statistics:
    total time:                          36.7335s
    total number of events:              10000
    total time taken by event execution: 36.7173s
    response time:
         min:                                  3.43ms
         avg:                                  3.67ms
         max:                                  8.34ms
         approx.  95 percentile:               3.79ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   36.7173/0.00

RAMテスト

sysbench 1.0:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time

Initializing worker threads...

Threads started!

Operations performed: 104857600 (2172673.64 ops/sec)

102400.00 MiB transferred (2121.75 MiB/sec)

General statistics:
    total time:                          48.2620s
    total number of events:              104857600
    total time taken by event execution: 17.4161s
    response time:
         min:                                  0.00ms
         avg:                                  0.00ms
         max:                                  0.17ms
         approx.  95 percentile:               0.00ms

Threads fairness:
    events (avg/stddev):           104857600.0000/0.00
    execution time (avg/stddev):   17.4161/0.00

Docker+Kataコンテナを使用したsysbenchの実行

プロセッサテスト

sysbench 1.0:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time

Prime numbers limit: 20000

Initializing worker threads...

Threads started!

General statistics:
    total time:                          36.5747s
    total number of events:              10000
    total time taken by event execution: 36.5594s
    response time:
         min:                                  3.43ms
         avg:                                  3.66ms
         max:                                  4.93ms
         approx.  95 percentile:               3.77ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   36.5594/0.00

RAMテスト

sysbench 1.0:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time

Initializing worker threads...

Threads started!

Operations performed: 104857600 (2450366.94 ops/sec)

102400.00 MiB transferred (2392.94 MiB/sec)

General statistics:
    total time:                          42.7926s
    total number of events:              104857600
    total time taken by event execution: 16.1512s
    response time:
         min:                                  0.00ms
         avg:                                  0.00ms
         max:                                  0.43ms
         approx.  95 percentile:               0.00ms

Threads fairness:
    events (avg/stddev):           104857600.0000/0.00
    execution time (avg/stddev):   16.1512/0.00

原則として、状況はすでに明らかですが、テストを数回実行して外れ値を除去し、結果を平均化することがより最適であるため、まだテストは行いません。

所見

このようなコンテナーは起動に約 XNUMX ~ XNUMX 倍の時間がかかります (containerd を使用する場合の同様のコマンドの通常の実行時間は XNUMX 分の XNUMX 秒未満です) にもかかわらず、絶対的な起動時間を考慮すると、依然として非常に速く動作します (上記の例では、コマンドは平均 XNUMX 秒で実行されます)。 CPU と RAM の簡単なテストの結果は、ほぼ同じ結果を示しました。特に kvm などの適切に実行されたメカニズムを使用して分離が提供されているという事実を考慮すると、これは喜ばしいことではありません。

お知らせ

この記事はレビューですが、代替ランタイムを感じる機会を提供します。 アプリケーションの多くの領域はカバーされていません。たとえば、このサイトでは、Kata コンテナ上で Kubernetes を実行する機能について説明しています。 さらに、セキュリティ上の問題の発見、制限の設定、その他の興味深いことに焦点を当てた一連のテストを実行することもできます。

ここを読んで巻き戻してくださったすべての方々に、このテーマに関する今後の出版物がどのような出版物になるかはアンケートへの参加をお願いします。

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

Kata コンテナに関する記事を公開し続ける必要がありますか?

  • 視聴者の38%がはい、もっと書いてください!28

  • 視聴者の38%がいや、やめて…7

35 人のユーザーが投票しました。 7名のユーザーが棄権した。

出所: habr.com

コメントを追加します