![](\"https:\/\/rancher.com\/img\/blog\/2018\/what-is-gvisor-1.png\")
<\/p>\nLike many of us in the Kubernetes space, I\u2019m excited to check out the
\nshiny new thing. To be fair, we\u2019re all working with an amazing product
\nthat is younger than my pre-school aged daughter. The shiny new thing at
\nKubeCon Europe was a new container runtime authored by Google named
\ngVisor. Like a cat to catnip, I had to check this out and share it with
\nyou.<\/p>\n
gVisor is a sandboxed container runtime, that acts as a user-space
\nkernel. During KubeCon Google announced that they open-sourced it to the
\ncommunity. Its goal is to use paravirtualization to isolate
\ncontainerized applications from the host system, without the heavy
\nweight resource allocation that comes with virtual machines.<\/p>\n
No. If you\u2019re running production workloads, don\u2019t even think about it!
\nRight now, this is a metaphorical science experiment. That\u2019s not to say
\nyou may not want to use it as it matures. I don\u2019t have any problem with
\nthe way it\u2019s trying to solve process isolation and I think it\u2019s a good
\nidea. There are also alternatives you should take the time to explore
\nbefore adopting this technology in the future.<\/p>\n
That being said, if you want to learn more about it, when you\u2019ll want to
\nuse it, and the problems it seeks to solve, keep reading.<\/p>\n
As an operator, you\u2019ll want to use gVisor to isolate application
\ncontainers that aren\u2019t entirely trusted. This could be a new version of
\nan open source project your organization has trusted in the past. It
\ncould be a new project your team has yet to completely vet or anything
\nelse you aren\u2019t entirely sure can be trusted in your cluster. After all,
\nif you\u2019re running an open source project you didn\u2019t write (all of us),
\nyour team certainly didn\u2019t write it so it would be good security and
\ngood engineering to properly isolate and protect your environment in
\ncase there may be a yet unknown vulnerability.<\/p>\n
Sandboxing is a software management strategy that enforces isolation
\nbetween software running on a machine, the host operating system, and
\nother software also running on the machine. The purpose is to constrain
\napplications to specific parts of the host\u2019s memory and file-system and
\nnot allow it to breakout and affect other parts of the operating system.<\/p>\n
<\/p>\n
The virtual machine (VM) is a great way to isolate applications from the
\nunderlying hardware. An entire hardware stack is virtualized to protect
\napplications and the host kernel from malicious applications.<\/p>\n
![](\"https:\/\/rancher.com\/img\/blog\/2018\/what-is-gvisor-2.png\")
<\/p>\n
As stated before, the problem is that VMs are heavy. The require set
\namounts of memory and disk space. If you\u2019ve worked in enterprise IT, I\u2019m
\nsure you\u2019ve noticed the resource waste.<\/p>\n
Some projects are looking to solve this with lightweight OCI-compliant
\nVM implementations. Projects like Kata containers are bringing this to
\nthe container space on top of runV, a hypervisor based runtime.<\/p>\n
![](\"https:\/\/rancher.com\/img\/blog\/2018\/what-is-gvisor-3.png\")
<\/p>\n
Microsoft is using a similar technique to isolate workloads using a
\nvery-lightweight Hyper-V virtual machine when using Windows Server
\nContainers with Hyper-V isolation.<\/p>\n
![](\"https:\/\/rancher.com\/img\/blog\/2018\/what-is-gvisor-4.png\")
<\/p>\n
This feels like a best-of-both worlds approach to isolation. Time will
\ntell. Most of the market is still running docker engine under the
\ncovers. I don\u2019t see this changing any time soon. Open containers and
\ncontainer runtimes certainly will begin taking over a share of the
\nmarket. As that happens, adopting multiple container runtimes will be an
\noption for the enterprise.<\/p>\n
gVisor intends to solve this problem. It acts as a kernel in between the
\ncontainerized application and the host kernel. It does this through
\nvarious mechanisms to support syscall limits, file system proxying, and
\nnetwork access. These mechanisms are a paravirtualization providing a
\nvirtual-machine like level of isolation, without the fixed resource cost
\nof each virtual machine.<\/p>\n
![](\"https:\/\/rancher.com\/img\/blog\/2018\/what-is-gvisor-5.png\")
<\/p>\n
gVisor the runtime is a binary named runsc (run sandboxed container) and
\nis an alternative to runc or runv if you\u2019ve worked with kata containers
\nin the past.<\/p>\n
gVisor isn\u2019t the only way to isolate your workloads and protect your As docker supports multiple runtimes, it will work with runsc. To use it docker run \u2013runtime=runsc hello-world<\/p>\n Kubernetes support for gVisor is experimental and implemented via the It depends. Currently gVisor only supports single-container pods. Here Ultimately support for any given application will depend on whether the Again, this depends. gVisor\u2019s \u201cSentry\u201d process is responsible for The architecture of gVisor suggests it would be able to enable greater A quick note about network access and performance. Network access is Rancher currently cannot be used to provision CRI-O backed Kubernetes We\u2019ll continue to monitor gVisor as it matures. As such, we\u2019ll add more Jason Van Brackel<\/p>\n Senior Solutions Architect<\/p>\n Jason van Brackel is a Senior Solutions Architect for Rancher. He is also the organizer of the Kubernetes Philly Meetup and loves teaching at code camps, user groups and other meetups. Having worked professionally with everything from COBOL to Go, Jason loves learning, and solving challenging problems.<\/p>\n
\ninfrastructure. Technologies like SELinux, seccomp and Apparmor solve a
\nlot of these problems (as well as others). It would behoove you as an
\noperator and an engineer to get well acquainted with these technologies.
\nIt\u2019s a lot to learn. I\u2019m certainly no expert, although I aspire to be.
\nDon\u2019t be a lazy engineer. Learn your tools, learn your OS, do right by
\nyour employer and your users. If you want to know more go read the man
\npages and follow Jessie
\nFrazelle<\/a>.
\nShe is an expert in this area of computing and has written a treasure
\ntrove on it.<\/p>\nUsing gVisor with Docker<\/h2>\n
\none must build and install the runsc container runtime binary and
\nconfigured docker\u2019s \/etc\/docker\/daemon.json file to support the gVisor
\nruntime. From there a user may run a container with the runsc runtime by
\nutilizing the \u2013runtime flag of the docker run command.<\/p>\nUsing gVisor with Kubernetes<\/h2>\n
\nCRI-O CRI implementation. CRI-O is an implementation of the Kubernetes
\nContainer Runtime Interface. Its goal is to allow Kubernetes to use any
\nOCI compliant container runtime (such as runc and runsc). To use this
\none must install runsc on the Kubernetes , then configure cri-o to use
\nrunsc to run untrusted workloads in cri-o\u2019s \/etc\/crio\/crio.conf file.
\nOnce configured, any pod without the io.kubernetes.cri-o.TrustedSandbox
\nannotation (or the annotation set to false), will be run with runsc.
\nThis would be as an alternative to using the Docker engine powering the
\ncontainers inside Kubernetes pods.<\/p>\nWill my application work with gVisor<\/h2>\n
\nis a list of known working applications that have been tested with
\ngVisor.<\/p>\n
\nsyscalls used by the application are supported.<\/p>\nHow does it affect performance?<\/h2>\n
\nlimting syscalls and requires a platform to implement context switching
\nand memory mapping. Currently gVisor supports Ptrace and KVM, which
\nimplement these functions differently, are configured differently, and
\nsupport different node configurations to operate effectively. Either
\nwould affect performance differently than the other.<\/p>\n
\napplication density over VMM based configurations but may suffer higher
\nperformance penalties in sycall-rich applications.<\/p>\nNetworking<\/h3>\n
\nachieved via an L3 userland networking stack subproject called netstack.
\nThis functionality can be bypassed in favor of the host network to
\nincrease performance.<\/p>\nCan I use gVisor with Rancher?<\/h2>\n
\nclusters as it relies heavily on the docker engine. However, you
\ncertainly manage CRI-O backed clusters with Rancher. Rancher will manage
\nany Kubernetes server as we leverage the Kubernetes API and our
\ncomponents are Kubernetes Custom Resources.<\/p>\n
\nsupport for gVisor with Rancher as need arises. Like the evolution of
\nWindows Server Containers in Kubernetes, soon this project will become
\npart of the fabric of Kubernetes in the Enterprise.<\/p>\n![\"Jason](\"https:\/\/rancher.com\/img\/bio\/jason-van-brackel.jpg\")
<\/p>\n