Are you familiar with kubernetes/containers?

[kalos]

Hello!

Are you familiar with kubernetes/containers?

I have left behind regarding these technologies and wonder if you can briefly explain how you understand its purposes and use cases?

I remember decades ago there was the concept of 'sandbox' where basically you would be able to run executables locally in a way that is isolated from the OS for security purposes. E.g. if you didn't know if something is a virus, you would run it in a sandbox so that whatever it reads/writes will be emulated locally instead of messing the OS.

Then there was the concept of 'portable apps' which still exists and its purpose was that you can migrate the app to different machines without having to install it and this would ensure that whatever permanent changes you make to the app such as choosing particular Options (i.e. dark theme) would be transferred or maintained within the app.

Is it accurate to say kubernetes/containers are kind of these concepts? i.e. a sandbox or an sandboxed executable or a portable executable?

Regarding its purpose, is it instead of security or maybe in addition to security, some kind of repeatability and efficiency?

• I understand efficiency as 'in case the executable would mess the OS resources if run unrestricted e.g. a very CPU consuming executable'
• I understand repeatability as 'in case the executable would be incompatible with the OS e.g. a Linux executable running in a Windows environment'

I read/watched some kubernetes/containers explanations but they were not making much sense :/ and especially how different they are from sandboxes and portable apps.

Thanks!

[wraith808]

Take a look at the official breakdown of it.

https://kubernetes.i...s/concepts/overview/

I mean, you could use it as a sandbox, but that's not really the purpose. And you definitely wouldn't use it for portable apps. And that's probably the reason you're having hard time wrapping your head around it- because it's not really analogous to either.

[Shades]

According to Youtube channel 'Dave's Garage' Docker containers can be up to 15% slower than running the same tool on bare metal. He also tried VMs on the same hardware and performance losses were between 1 and 3%.

So containers are most of the time not the smartest choice, if pure performance is your goal. Containers do make things more convenient.

Containerization is actually a pretty old concept, thought up around 20 years ago. Meaning it is not something new, so you could have known about it already. 

Containerization is not like sandboxing, but if one would need to describe it in a few succinct words to a layperson, then perhaps you should mention sandboxing. Container software, like Docker, embed themselves into the operating system at a pretty low level. It detects the hardware resources that are available and assigns these resources to the active containers as they need those resources.

Having a few active containers, you can be sure that the container software is managing the containers as efficient as possible withing the resource parameters you have configured. The operating system does come with such functionality, and it is good at it. But processes can sometimes bring the whole system down. Much less of a problem with containers.

Portable apps and sandboxes require to be run inside the operating system. Containers, in essence, do not.

Containers can easily be cloned and recreated, by scripts if you so prefer, hence these are ideal for automating the deployment of a test-/acceptance-/production-environment, adding and removing compute capacity when you/your company needs it. Making containers ideal for cloud computing and/or the enthusiast that owns his/her own testlab at home.

If you decide to get your feet wet and start playing with Docker, setup a Linux VM in your Windows installation and install Docker in that VM. Docker works very well in Linux. They do create a Windows installer of Docker, but that is not nearly as good an experience as the Linux version is. If you think that the Docker version for Windows works well, than you haven't seen it in action on Linux. The Docker installer also affects what other software you can install in Windows, especially with regards to virtualization and networking functionality.

If your Windows is modern enough to run WSL2 from Microsoft, you could use that to install the Linux version from Docker.

Containers, when setup well, occupy a lot less storage space on your drives than VMs do. Containers and Virtual Machines have very much in common, but containers have the advantage of occupying (much) less storage space. However, that is not always the case, as not every containerized project is setup that well. 

Containerization is a pretty well thought out concept for the Linux operating system. Windows and MacOS are much more lacking in that regard.
While a Docker container will work on Linux as well as on MacOS or Windows, other forms of containers do not. At least, I have not heard of them, but I have been playing with these things for a month and a half myself.

'LXC' and 'AppImage' are more mature Linux containers. And it doesn't matter which distribution of Linux (Debian, Ubuntu, RedHat, OpenSuse, Arch, Gentoo etc.) that these containers are executed on, they simply work. No need to install anything, just execute and you have working software.
Docker, Flatpak, Snap all require you to install their software first and each system is not interchangeable.

Now, if you are playing around with 'Proxmox' (open source virtualization software that put many similar commercial offerings to shame), You can directly run LXC containers as a VM in Proxmox. That is more or less all the advantages from containers and VMs all rolled into one.

I haven't played around with Kubernetes, and I only know that Google uses this software to run all the services they provide to end-users. I know that Google uses the most standard computer hardware as much as possible inside their server parks all over the globe. Much cheaper and easier to repair/maintain than server grade hardware, which can be hard to get and is always very expensive to buy. Running Kubernetes divides the workload of all their services over the hardware that is active. So when some cheap server fails, Kubernetes diverts the Google services to the remaining hardware without the end-user knowing there was any kind of hardware problem.

Haven't learned much more than that about Kubernetes.

[wraith808]

According to Youtube channel 'Dave's Garage' Docker containers can be up to 15% slower than running the same tool on bare metal. He also tried VMs on the same hardware and performance losses were between 1 and 3%.

-Shades (December 23, 2022, 06:24 AM)

That really depends on how it's set up and have nothing to do with containerization. Containers run on Linux namespaces which are native to the Linux Kernel so are not inherently slower, and can be run on bare metal rather than using a hypervisor. A bare metal install of Linux runs in namespace 0. It's not inherently better performing than any other namespace. As a result, a container can perform the same as native hardware.

There are however some practical bottlenecks. Containers usually don't mount native disk volumes; they tend to map images from the parent namespace. Namespaces usually don't have direct network access. Namespaces usually aren't fully privileged.

You can mount native volumes to a namespace. You can attach network devices to a container. You can make a container privileged. You can even remove some of the barriers between namespaces.

Long story short: CPU and memory performance should pretty much always be the same as native, unless you constrain them. Disk and network performance will be reduced unless you specifically address those limitations.

[kalos]

Thanks! But *why* would I want to use containers/kubernetes?

For example:

• I use the cloud so that I do not have to have my laptop switched on 24/7 and also for performance reasons.
• I use sandbox for security and not to mess the whole OS.
• I use VM to run stuff in my local OS that are not built/available/ported to my local OS.
• I use portable apps for portability, easy deployment, easy migration.

Why would I use containers/kubernetes? I assume containers/kubernetes is an "environment" and what you actually run can be anything e.g. a python script etc? Why would I want to use such special environment if not for performance?

[Shades]

And what if the drive in your laptop would die tomorrow, without any indication/warning?

In your case, you would get a new drive, restore a backup and probably spend the rest of the day tweaking things just like they were just before the drive died.

Now imagine that your laptop acted as a server and that you had an employee who needed that server to do his/her work. You were losing your own time, money and effort and the time, effort and profits from the work your employee does.

Increase that scale again to a company of 100 people, 1000 people etc. Preventative maintenance is a thing. Having the ability to move software/services inside a container to another server, without interruption of service to your employees and/or clients, to do the actual preventative maintenance on the original server, reduces the risk of failure or unplanned downtime.

Usually an enterprise grade server operates for about 3 years after it was purchased new. In that period it is unlikely that there is risk of failure/unplanned downtime. After that period the risk goes up, so the server is being repurposed for less important tasks or sold altogether. By that amount of time CPU's and other hardware have been either expanded upon or made much more efficient energy-wise. So in datacenters/serverparks (cloud and on-premise), servers are being replaced on regular intervals. And such things need to happen without interruptions, else it costs the business too much. If setup correctly, Kubernetes/containers help out with that.

Kubernetes also allows you to scale computer resources up at a moment's notice, when you need these resources. And scale down when you don't. Without the concept of Kubernetes, the cloud as you experience it today would not exist.

From the tone of your last post I gather that these things don't matter to you. And that is fine. But for those that run a business, it is. The extra layer of abstraction behind these concepts provide, keep their whole computing environment available to employees/clients, enabling those to generate their profits. Within enterprise environments availability exceeds performance, not by lot of course.

If you have a free weekend and the budget or have access to old, yet reasonably modern computers, I would suggest to start playing with containers/Kubernetes and ProxMox, so you'll get a first hand "feel" of what these concepts do. Likely you will not see a use case for yourself, but there is also a good chance that you'll come up with a use case that does work out for you.

[wraith808]

Thanks! But *why* would I want to use containers/kubernetes?

For example:

• I use the cloud so that I do not have to have my laptop switched on 24/7 and also for performance reasons.
• I use sandbox for security and not to mess the whole OS.
• I use VM to run stuff in my local OS that are not built/available/ported to my local OS.
• I use portable apps for portability, easy deployment, easy migration.

Why would I use containers/kubernetes? I assume containers/kubernetes is an "environment" and what you actually run can be anything e.g. a python script etc? Why would I want to use such special environment if not for performance?

-kalos (December 25, 2022, 11:50 AM)

There are a few situations where people use containers for more personal use applications, i.e. to package up something that's not a standard application, but more akin to something web hosted. But in most cases, you wouldn't. It's not something in general for use for personal applications.