3 ms·

>> 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 a

>> 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.

__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.