บทความนี้จะกล่าวถึงวิธีการทำงาน และจะมีส่วนที่ใช้งานได้จริงกับการเชื่อมต่อกับ Docker
เกี่ยวกับปัญหาทั่วไปเกี่ยวกับ Docker และแนวทางแก้ไขแล้ว วันนี้ผมจะอธิบายการใช้งานจาก Kata Containers โดยสังเขป Kata Containers เป็นรันไทม์คอนเทนเนอร์ที่ปลอดภัยโดยอิงจากเครื่องเสมือนที่มีน้ำหนักเบา การทำงานกับพวกเขานั้นเหมือนกับคอนเทนเนอร์อื่น ๆ แต่นอกจากนี้ยังมีการแยกที่เชื่อถือได้มากขึ้นโดยใช้เทคโนโลยีการจำลองเสมือนของฮาร์ดแวร์ โครงการเริ่มต้นในปี 2017 เมื่อชุมชนชื่อเดียวกันเสร็จสิ้นการรวมแนวคิดที่ดีที่สุดจาก Intel Clear Containers และ Hyper.sh RunV หลังจากนั้นงานยังคงสนับสนุนสถาปัตยกรรมต่างๆ รวมถึง AMD64, ARM, IBM p- และ z -ชุด. นอกจากนี้ยังรองรับการทำงานภายในไฮเปอร์ไวเซอร์ QEMU, Firecracker และยังมีการทำงานร่วมกับคอนเทนเนอร์อีกด้วย โค้ดได้ที่ ภายใต้ใบอนุญาต MIT
คุณสมบัติหลัก
- การทำงานกับคอร์ที่แยกจากกัน ทำให้สามารถแยกเครือข่าย หน่วยความจำ และ I/O ได้ จึงเป็นไปได้ที่จะบังคับใช้การแยกฮาร์ดแวร์ตามส่วนขยายของเวอร์ชวลไลเซชัน
- รองรับมาตรฐานอุตสาหกรรมรวมถึง OCI (รูปแบบคอนเทนเนอร์), Kubernetes CRI
- ประสิทธิภาพที่สม่ำเสมอของคอนเทนเนอร์ Linux ทั่วไป การแยกที่เพิ่มขึ้นโดยไม่มีค่าใช้จ่ายด้านประสิทธิภาพเหมือน VM ปกติ
- ขจัดความจำเป็นในการเรียกใช้คอนเทนเนอร์ภายในเครื่องเสมือนเต็มรูปแบบ อินเทอร์เฟซทั่วไปทำให้การรวมและเปิดใช้งานง่ายขึ้น
การติดตั้ง
มี ตัวเลือกการติดตั้ง ฉันจะพิจารณาการติดตั้งจากที่เก็บตามระบบปฏิบัติการ Centos 7
มันเป็นสิ่งสำคัญ: งาน Kata Containers รองรับเฉพาะบนฮาร์ดแวร์ การส่งต่อเวอร์ชวลไลเซชันอาจใช้ไม่ได้เสมอไปเช่นกัน ต้องการการสนับสนุน sse4.1 จากโปรเซสเซอร์
การติดตั้ง Kata Containers นั้นค่อนข้างง่าย:
ติดตั้งยูทิลิตี้สำหรับการทำงานกับที่เก็บ:
# 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การตั้งค่า
ฉันจะตั้งค่าให้ทำงานกับนักเทียบท่า การติดตั้งเป็นเรื่องปกติ ฉันจะไม่อธิบายรายละเอียดเพิ่มเติม:
# 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การทดสอบสมรรถนะ
หากคุณเริ่มคอนเทนเนอร์ก่อนที่จะรีสตาร์ทนักเทียบท่า คุณจะเห็นว่า 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 เป็นตัวอย่างหลัก .
เรียกใช้ sysbench โดยใช้ Docker+containerd
การทดสอบโปรเซสเซอร์
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การทดสอบแรม
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รัน sysbench โดยใช้ Docker+Kata Containers
การทดสอบโปรเซสเซอร์
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การทดสอบแรม
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โดยหลักการแล้ว สถานการณ์มีความชัดเจนอยู่แล้ว แต่จะเหมาะสมกว่าที่จะทำการทดสอบหลายๆ ครั้ง ลบค่าผิดปกติและหาค่าเฉลี่ยของผลลัพธ์ ดังนั้นฉันจึงยังไม่ทำการทดสอบเพิ่มเติม
ผลการวิจัย
แม้ว่าคอนเทนเนอร์ดังกล่าวจะใช้เวลาเริ่มต้นนานกว่าห้าถึงสิบเท่า (เวลารันโดยทั่วไปสำหรับคำสั่งที่คล้ายกันเมื่อใช้คอนเทนเนอร์น้อยกว่าหนึ่งในสามของวินาที) พวกมันยังคงทำงานค่อนข้างเร็วหากเราใช้เวลาเริ่มต้นสัมบูรณ์ (ที่นั่น เป็นตัวอย่างข้างต้น คำสั่งดำเนินการโดยเฉลี่ยสามวินาที) ผลลัพธ์ของการทดสอบอย่างรวดเร็วของ CPU และ RAM แสดงผลลัพธ์ที่เกือบจะเหมือนกัน ซึ่งไม่สามารถชื่นชมยินดีได้
การประกาศ
บทความนี้เป็นบทวิจารณ์ แต่เปิดโอกาสให้คุณได้สัมผัสกับรันไทม์ทางเลือก ไม่ครอบคลุมแอปพลิเคชันหลายส่วน เช่น เว็บไซต์อธิบายความสามารถในการเรียกใช้ Kubernetes บน Kata Containers นอกจากนี้ คุณยังสามารถเรียกใช้ชุดการทดสอบที่เน้นไปที่การค้นหาปัญหาด้านความปลอดภัย การตั้งค่าข้อจำกัด และสิ่งที่น่าสนใจอื่นๆ
ฉันขอให้ทุกคนที่ได้อ่านและย้อนกลับที่นี่เพื่อมีส่วนร่วมในการสำรวจซึ่งสิ่งพิมพ์ในอนาคตในหัวข้อนี้จะขึ้นอยู่กับ
เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้ , โปรด.
ฉันควรเผยแพร่บทความเกี่ยวกับ Kata Containers ต่อไปหรือไม่
-
ลด 80,0%ใช่ เขียนเพิ่ม!28
-
ลด 20,0%ไม่ อย่า…7
ผู้ใช้ 35 คนโหวต ผู้ใช้ 7 รายงดออกเสียง
ที่มา: will.com