| *** dlw has joined #kata-general | 01:48 | |
| *** Razva has left #kata-general | 05:19 | |
| *** jodh has joined #kata-general | 05:49 | |
| *** sjas has joined #kata-general | 06:40 | |
| *** jodh has quit IRC | 07:09 | |
| *** jodh has joined #kata-general | 07:11 | |
| *** jodh has joined #kata-general | 07:11 | |
| *** gwhaley has joined #kata-general | 08:02 | |
| *** GonZo2000 has joined #kata-general | 11:08 | |
| *** gwhaley has quit IRC | 11:16 | |
| *** gwhaley has joined #kata-general | 12:28 | |
| *** sjas has quit IRC | 12:46 | |
| *** GonZo2000 has quit IRC | 13:38 | |
| kata-irc-bot | <sudeep.batra> One generic queries, do we have a comparison between KataContainer and gVisor ? I can see that KataContainer is more matured whereas gVisor seems more experimental. But what the technical differences in terms of Architecture. | 13:59 |
|---|---|---|
| *** annabelleB has joined #kata-general | 14:15 | |
| kata-irc-bot | <anne> Hi @sudeep.batra -- we don't have a side-by-side diagram, so I'll do my best to write it out: gVisor and Kata are two very different approaches. gVisor uses a very lightweight kernel in the user space to filter what gets sent to the kernel space kernel/parent kernel. It’s essentially filtering syscalls to create isolation. Kata uses a lightweight virtualization layer to put a hard boundary around each container or pod. What solution i | 14:34 |
| kata-irc-bot | going to perform better for someone depends on their implementation—if it’s syscall heavy, exiting to the gVisor parent kernel isn’t going to be performant. If it isn’t, gVisor could be quite promising for them. As the gVisor team calls out in their docs, gVisor shouldn’t be seen as a replacement for hardening containers. | 14:34 |
| kata-irc-bot | <sudeep.batra> Thanks @anne, so for lightweight workload(lesser syscalls) - use gVisor , for more heavyweight Kata fits well. | 14:38 |
| kata-irc-bot | <sudeep.batra> But Can I say which one is more secure ? | 14:38 |
| kata-irc-bot | <sudeep.batra> and by more heavyweight - Can I say my VNFs that have need for SR-IOV,DPDK kindof performance requirements ? | 14:41 |
| kata-irc-bot | <eric.ernst> I think DPDK works with gvisor, per prior conversations with @jonolson | 14:47 |
| kata-irc-bot | <eric.ernst> Direct device assignment (SRIOV) wouldn't be supported AFAIU. | 14:47 |
| kata-irc-bot | <eric.ernst> I haven't invested much time in testing gVisor though. | 14:47 |
| kata-irc-bot | <jonolson> DPDK should work under gVisor in the same way VFIO or UIO would work with no sandboxing — no direct device assignment, as the Sentry kernel doesn’t have bits for PCI enumeration, etc. (let alone drivers) | 15:12 |
| *** fiddletwix has joined #kata-general | 15:25 | |
| kata-irc-bot | <eric.ernst> jon, maybe we can setup a tmux session for istio fun | 15:58 |
| kata-irc-bot | <sebastien.boeuf> @jonolson yep, let me know if you want to debug through tmux :slightly_smiling_face: | 15:59 |
| kata-irc-bot | <jonolson> @anne @sudeep.batra I’ve had a few conversations with gVisor folks internally since that initially wall-of-text dump a few weeks ago — one important aspect of the gVisor approach that I’d sorta glossed over is that it doesn’t _just_ filter the syscalls — instead, the Sentry fully-interprets the syscall, decides whether the underlying operation should be allowed, and then writes a new well-formed (unless there’s a bug in | 16:01 |
| kata-irc-bot | syscall with what the Sentry believes was the user-mode app’s intent | 16:01 |
| kata-irc-bot | <jonolson> This is the big distinction between gVisor and other filtering tech — you don’t need just a bug in gVisor’s admission control to feed bad data to the kernel, you also need a bug in how it authors the syscalls it writes based on that bad admission control decision (and you likely _also_ need a bug in the host kernel) — it’s the independent authoring that provides the “second layer” that Google is looking for when consum | 16:03 |
| kata-irc-bot | untrusted workloads. | 16:03 |
| kata-irc-bot | <jonolson> @sebastien.boeuf @eric.ernst Where are you all running? | 16:05 |
| kata-irc-bot | <eric.ernst> not sure if i should tell you ;) | 16:06 |
| kata-irc-bot | <sebastien.boeuf> lool | 16:07 |
| kata-irc-bot | <sebastien.boeuf> @jonolson don't worry about it | 16:07 |
| kata-irc-bot | <sebastien.boeuf> it's just an IP :slightly_smiling_face: | 16:07 |
| kata-irc-bot | <jonolson> Awwwwww :S | 16:08 |
| kata-irc-bot | <raravena80> We tried istio last year and abandoned it :,) hoping that it would be more stable at some point. | 16:09 |
| *** GonZo2000 has joined #kata-general | 16:30 | |
| *** jodh has quit IRC | 17:01 | |
| *** annabelleB has quit IRC | 17:02 | |
| *** annabelleB has joined #kata-general | 17:14 | |
| *** gwhaley has quit IRC | 17:33 | |
| *** oikiki has joined #kata-general | 18:34 | |
| *** annabelleB has quit IRC | 18:41 | |
| *** annabelleB has joined #kata-general | 19:02 | |
| *** annabelleB has quit IRC | 19:20 | |
| *** annabelleB has joined #kata-general | 19:41 | |
| *** GonZo2000 has quit IRC | 19:48 | |
| *** oikiki has quit IRC | 20:06 | |
| *** oikiki has joined #kata-general | 20:07 | |
| *** annabelleB has quit IRC | 20:11 | |
| *** oikiki has quit IRC | 21:13 | |
| *** oikiki has joined #kata-general | 21:17 | |
| *** annabelleB has joined #kata-general | 21:17 | |
| *** oikiki has quit IRC | 21:20 | |
| kata-irc-bot | <sudeep.batra> @jonolson, thanks, so the Sentry component puts a lot of intelligence, wondering thats a sustainable overhead when running workloads on scale- like 500 Servers or more. and am I hearing that there multiple places things can go wrong and effectively block my traffic :slightly_smiling_face: ? | 21:59 |
| *** annabelleB has quit IRC | 22:02 | |
| kata-irc-bot | <jonolson> Depends on what you mean by “500 servers or more” — if you mean 500 machines all running similar workloads, gVisor isn’t so different from ensuring stable operation on one machine — if you mean 500 distinct services, especially if they all make raw syscalls, then proving gVisor works for all of them is indeed a potential hurdle — if they’re mostly running with managed runtimes with well-known syscall surfaces, gVisor i | 22:04 |
| kata-irc-bot | tractable. | 22:04 |
| kata-irc-bot | <jonolson> In practice, though, yes, gVisor prioritizes density and security over syscall compatibility and performance — the coverage it has is generally quite good, but there’s always the chance that a new/unknown workload will run up against one of the rough edges | 22:05 |
| *** annabelleB has joined #kata-general | 22:49 | |
| kata-irc-bot | <kevin.fox> does containerd 1.1 with its native cri plugin map pods properly to a single vm, or does it launch one vm per container? | 23:22 |
| kata-irc-bot | <eric.ernst> it maps properly. | 23:26 |
| kata-irc-bot | <eric.ernst> VM isolation is at the pod level | 23:26 |
| kata-irc-bot | <kevin.fox> ok, cool. thanks. :slightly_smiling_face: | 23:27 |
| kata-irc-bot | <kevin.fox> do you know if there is there a docker release with 1.1 yet? | 23:27 |
| kata-irc-bot | <eric.ernst> I'm not sure. I don't deal with containerd that way. | 23:28 |
| kata-irc-bot | <eric.ernst> I just pull the tarball and configure k8s to use it. | 23:29 |
| kata-irc-bot | <eric.ernst> i can provide directions if this is the end goal for you... | 23:29 |
| kata-irc-bot | <kevin.fox> yes please. :slightly_smiling_face: | 23:30 |
| kata-irc-bot | <kevin.fox> https://docs.docker.com/release-notes/docker-ce/#stable-releases mentions 1.0.3. | 23:32 |
| kata-irc-bot | <eric.ernst> here's a highlevel: https://github.com/kata-containers/documentation/blob/master/how-to/how-to-use-k8s-with-cri-containerd-and-kata.md | 23:34 |
| kata-irc-bot | <eric.ernst> What's your host distro? | 23:34 |
| kata-irc-bot | <kevin.fox> el7. | 23:37 |
| kata-irc-bot | <kevin.fox> thanks for the doc. reading. :slightly_smiling_face: | 23:38 |
| *** annabelleB has quit IRC | 23:42 | |
| kata-irc-bot | <kevin.fox> yeah. those instructions look to be containerd 1.0.x based. | 23:45 |
| kata-irc-bot | <kevin.fox> that should work. | 23:45 |
| kata-irc-bot | <eric.ernst> here's a super easy script you may like: ``` echo "Install Utilities" sudo dnf -y install tc go git wget unzip vim echo 'export GOPATH="$HOME/go"' | sudo tee -a /etc/profile echo 'export PATH="$PATH:$GOPATH/bin"' | sudo tee -a /etc/profile source /etc/profile VERSION="1.1.0" echo "Install Containerd ${VERSION}" wget -q https://storage.googleapis.com/cri-containerd-release/cri-containerd-${VERSION}.linux-amd64.tar.gz sudo tar -C / | 23:45 |
| kata-irc-bot | -xzf cri-containerd-${VERSION}.linux-amd64.tar.gz sudo systemctl start containerd echo "Install k8s binaries" cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF sudo | 23:45 |
| kata-irc-bot | setenforce 0 sudo yum install -y kubelet-1.10.* kubeadm kubectl echo "Setup Kubelet" cat <<EOF | sudo tee /etc/systemd/system/kubelet.service.d/0-containerd.conf [Service] Environment="KUBELET_EXTRA_ARGS=--container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///run/containerd/containerd.sock" EOF sudo modprobe br_netfilter sudo systemctl daemon-reload && sudo | 23:45 |
| kata-irc-bot | systemctl enable kubelet && sudo systemctl start kubelet ``` | 23:45 |
| kata-irc-bot | <eric.ernst> that's how I do it. | 23:45 |
| kata-irc-bot | <kevin.fox> cool. thanks. :slightly_smiling_face: | 23:46 |
| kata-irc-bot | <eric.ernst> n/p | 23:46 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!