この記事ではその仕組みについて説明します
Docker に関する一般的な問題とその解決策について
主な機能
- 別のコアを使用してネットワーク、メモリ、I/O を分離し、仮想化拡張機能に基づいてハードウェア分離を強制的に使用することができます。
- OCI (コンテナ形式)、Kubernetes CRI などの業界標準のサポート
- 通常の Linux コンテナの一貫したパフォーマンス、通常の VM のパフォーマンス オーバーヘッドなしで分離性を強化
- 本格的な仮想マシン内でコンテナを実行する必要がなくなり、汎用インターフェイスにより統合と起動が簡素化されます。
インストール
あり
それが重要だ: 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