4 ms·

https://www.katacoda.com/learn https://www.katacoda.com/learn https://www.katacoda.com/courses/kubernetes/playground https://www.katacoda.com/courses/kubernete

https://www.katacoda.com/learn https://www.katacoda.com/learn https://www.katacoda.com/courses/kubernetes/playground https://www.katacoda.com/courses/kubernetes/playground

andrewstuart 5y ago
I'm looking for words that explain why containers are a great thing, why they are more simple than I thought, how they aren't bound to one specific operating system kernel, or something that tells me why they're good, what the upside is. I want to hear the passionate beliefs of someone who loves them.
- sneak 5y ago
  Without a bind mount, their state is explicitly contained. You can run one, delete it, and run it again, and know that your host system is unmodified inbetween, and that the state is coming up brand new the second time. It's the reproducibility of a vm without the overhead of a whole 'nother OS/boot. You can keep all of the state in a single volume, and can back it up or move it to another machine and relaunch it with a minimum of fuss.
  - andrewstuart 5y ago
    >> move it to another machine Just any machine at all? I hear people say things like "move it to another machine" but I'm imagining a whole bunch of caveats are left out such as "move it to another machine wherein W,X,Y,Z must all be version foo and this thingy must match that thingy and in fact no you can't really move it to another machine without first replicating the underlying machines your moving from and to". You can hear my cynicism unfortunately.
    - __d 5y ago
      In practice, this isn't a problem. Any reasonably modern Linux kernel will do. The container image will usually be based on a Linux distribution (so, Ubuntu if you want it, often something lightweight like Alpine). Most applications don't actually see the kernel: they see the system library (eg. glibc, musl) and it hides differences in system call versions, etc. This is not a problem in general usage. A container will work on basically any Linux kernel.
    - __d 5y ago
      A virtual machine runs a kernel on an virtualized CPU. Different CPU versions exist, but so long as they have the basic virtualization extensions, the hyperviser will be fine. From inside the VM, it looks like you own the CPU. A container runs applications on a virtualized kernel (kinda). Different kernel version exist, but so long as they have the basic namespacing extensions, the container will be fine. From inside the container, it looks like you own the kernel. It's like a chroot, but for everything. You have your own init, your own daemons, your own applications.
    - sneak 5y ago
      As long as it's got the same vlans (or your sidecar container can hook it up to the appropriate service mesh/router or update a load balancer backend) then yup. The entire userspace is inside the container. The kernel version doesn't need to match, anything not ancient will be fine. Think of it like a tar of a chroot, although that is an oversimplification.
  - kasey_junk 5y ago
    This presumes you trust the workload in the container (which you might!). Containers are not an adequate security boundary for untrusted workloads to assume they leave the host unchanged.

https://www.katacoda.com/learn https://www.katacoda.com/learn https://www.katacoda.com/courses/kubernetes/playground https://www.katacoda.com/courses/kubernetes/playground

andrewstuart 5y ago

I'm looking for words that explain why containers are a great thing, why they are more simple than I thought, how they aren't bound to one specific operating system kernel, or something that tells me why they're good, what the upside is. I want to hear the passionate beliefs of someone who loves them.

sneak 5y ago
Without a bind mount, their state is explicitly contained. You can run one, delete it, and run it again, and know that your host system is unmodified inbetween, and that the state is coming up brand new the second time. It's the reproducibility of a vm without the overhead of a whole 'nother OS/boot. You can keep all of the state in a single volume, and can back it up or move it to another machine and relaunch it with a minimum of fuss.
- andrewstuart 5y ago
  >> move it to another machine Just any machine at all? I hear people say things like "move it to another machine" but I'm imagining a whole bunch of caveats are left out such as "move it to another machine wherein W,X,Y,Z must all be version foo and this thingy must match that thingy and in fact no you can't really move it to another machine without first replicating the underlying machines your moving from and to". You can hear my cynicism unfortunately.
  - __d 5y ago
    In practice, this isn't a problem. Any reasonably modern Linux kernel will do. The container image will usually be based on a Linux distribution (so, Ubuntu if you want it, often something lightweight like Alpine). Most applications don't actually see the kernel: they see the system library (eg. glibc, musl) and it hides differences in system call versions, etc. This is not a problem in general usage. A container will work on basically any Linux kernel.
  - __d 5y ago
    A virtual machine runs a kernel on an virtualized CPU. Different CPU versions exist, but so long as they have the basic virtualization extensions, the hyperviser will be fine. From inside the VM, it looks like you own the CPU. A container runs applications on a virtualized kernel (kinda). Different kernel version exist, but so long as they have the basic namespacing extensions, the container will be fine. From inside the container, it looks like you own the kernel. It's like a chroot, but for everything. You have your own init, your own daemons, your own applications.
  - sneak 5y ago
    As long as it's got the same vlans (or your sidecar container can hook it up to the appropriate service mesh/router or update a load balancer backend) then yup. The entire userspace is inside the container. The kernel version doesn't need to match, anything not ancient will be fine. Think of it like a tar of a chroot, although that is an oversimplification.
- kasey_junk 5y ago
  This presumes you trust the workload in the container (which you might!). Containers are not an adequate security boundary for untrusted workloads to assume they leave the host unchanged.