Comments (6)
I believe some of the confusion in this thread is because Docker also has a flag --network=host
. It's important to note that runsc --network=host
and docker run --network=host
mean different things.
docker run --network=host
removes the use of network namespaces from Docker containers. This means a Docker container can bind to the host network interface directly. When using this flag, there is no need to use the-p
flag, because the container has direct access to the host network interface and can bind on it directly. Therefore, Docker doesn't need to set up a port forwarding rule to the network namespace of the container (that's what-p
does).runsc --network=host
changes the technique that gVisor uses to implement the network stack visible to the sandboxed application. The default value (runsc --network=sandbox
) causes gVisor to reimplement its own network stack in Go. This is the most secure option (which is why it's the default), but it is also the slowest, because gVisor's network stack isn't as optimized as Linux's network stack it. By contract,runsc --network=host
causes gVisor to pass through network-related system calls to the host kernel. This means that when a sandboxed application issues a network-related system call, gVisor still intercepts it, and then passes it on to the host kernel (Linux). This is a lower degree of protection, because Linux's network stack has historically had more vulnerabilities inside of it, and is written in a memory-unsafe language. However, it is still a strictly better degree of protection than usingrunc
, because all system calls still get intercepted by gVisor and still need to go through gVisor's seccomp filters, which limits the total set of possible system calls that make it through. (At the same time, these reasons are also why this is still slower than running unsandboxed withrunc
.)
When you use runsc --network=host
with docker run
(without passing a --network
option to docker run
), the container still runs in a network namespace on the host. This means that you still need to add -p
to forward the port, and this means Linux still adds overhead because of the forwarding rule it adds to cross over the network namespace boundary.
This means that if you want to compare unsandboxed Docker performance with --network=host
set on the unsandboxed container, the most fair comparison for gVisor is to set both runsc --network=host
and docker run --network=host
. These flags are independent.
Now, one more thought about Redis benchmarking. When you run a Redis benchmark, it matters a lot how you run it. If you run both client and server on the same machine, then the comparison will not be fair when you use unsandboxed containers. This is because Linux will get to skip much of the network-related overhead it has to do, because packets get relayed entirely in the local network stack. By contrast, when running with runsc
, Linux cannot do this optimization, and therefore the packet has to actually make all its way through the network stack and into gVisor's own network stack. For the comparison to be fair, the client and the server needs to live on separate machines, or they have to at least go through separate network devices.
I will close this issue since there is no gVisor bug here as far as I can tell. If you have more questions around benchmarking or are finding abnormal results, feel free to open a different issue or email the gvisor-users mailing list.
from gvisor.
you docker command doesn't expose 9090 port of the container.
instead,
docker run -p 9090:9090 --runtime=runsc-kvm-host -v /home/test_suite:/home --rm -it ubuntu sh
should work for you
At the host, you will be able to see
$ telnet localhost 9090
Trying ::1...
Connected to localhost.
Escape character is '^]'.
From the container, I assume you will also something like
# netcat -v -l -p 9090
listening on [any] 9090 ...
getsockopt failed : Protocol not available
IP options: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : Protocol not available
172.17.0.1: inverse host lookup failed: Unknown host
connect to [172.17.0.2] from (UNKNOWN) [172.17.0.1] 45068
But i think there is nothing it has to do with network here, they are some socket protocol not implemented by gVisor for syscall getsockopt.
If you are interested, please feel free to enable strace and implement the protocol.
Let me know how it works for you
from gvisor.
Thanks for your kindly help. I'm sorry for the beginner's mistake I made due to my unfamiliarity with Docker. It led me to suspect that the reason for the failure in using the Host network might be the degraded performance of Redis compared to not using the Host network.
Specifically, when using runsc as the runtime, the Redis Ping performance decreased from 3101 ops/sec to 2504 ops/sec when using the Host network. In contrast, when using runc as the runtime, the Redis Ping performance increased from 6218 ops/sec to 10369 ops/sec when using the Host network.
I'm trying to identify the cause and suspect that it might be related to successfully using the Host network. Could you provide some guidance on this issue?
from gvisor.
Did you by any chance flip runc and runsc in the above comment?
from gvisor.
@hbhasker No, runsc as runtime, redis performance is even worse when using host network. Could you reproduce it?
from gvisor.
I expect that with runsc especially for ping pong traffic. The reason is host network support is implemented by proxying system calls straight to the host kernel which involves a VMEXIT in runsc making it very expensive. Host mode is useful for high throughout but not for low latency ping pong traffic.
Also your comment has runsc flipped with runc.
"when using runsc as the runtime, the Redis Ping performance decreased from 3101 ops/sec to 2504 ops/sec when using the Host network. In contrast, when using runc as the runtime, the Redis Ping performance increased from 6218 ops/sec to 10369 ops/sec when using the Host network."
from gvisor.
Related Issues (20)
- runsc --platform=systrap fails with "panic: seccomp failed: invalid argument" HOT 3
- Problem in building gvisor on ARM64 HOT 4
- [Feature] Asking for support for termux on android(with termux-glibc) HOT 3
- NV2080_CTRL_CMD_GRMGR_GET_GR_FS_INFO: Missing nvproxy ioctl used by NCCL HOT 2
- feed does not validate HOT 1
- Restoring a checkpointed container with a different OCI spec HOT 8
- Mark C ABI structs with `structs.HostLayout`
- segfault: buffer.View possibly released twice resulting in nil chunk HOT 8
- /proc/sys/net/core/rmem_default is visible in non-root network namespaces in recent Linux kernels HOT 1
- //test/syscalls/linux:prctl_test fails to build on x86_64 host because of aarch64 dependencies HOT 2
- runsc: Duplicate container creation deletes the existing container and causes resources leak
- File descriptors not being closed on write to mountpoint-s3 HOT 16
- runsc (in docker): fork/exec /proc/self/exe: read-only file system HOT 5
- gVisor CNI tutorial is not working as expected
- Support no-op `personality(2)` bits
- Regression in recent version? error: setsockopt(..., IP_MTU_DISCOVER, IP_PMTUDISC_OMIT...) failed: Not supported HOT 5
- No obvious way to checkpoint a container when TCP sockets have been recently closed and are in TIME_WAIT state in the kernel HOT 2
- sysctl options declared in config.json not applied to container HOT 3
- Poor performance when switching to multiple CPU Cores HOT 7
- Runtime fails to mount /sys when --tpuproxy is provided HOT 20
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gvisor.