This blog post continues from where we left in our earlier blog post, where we discussed how systemd and podman fits in together to run and manage containers as systemd services. We discussed how we can do the same for a specific containers and learned to create generic systemd unit files. We also discussed few use cases where this integration is useful. As we know, pods in podman are a way to group and manage multiple application containers as one. So we can start them together, manage them together and then remove them together once done. If we do need, we can manage them individually as well. Basics of pods are covered here.Read More »
By default, containers / pods are allocated unbound resources in the Kubernetes cluster. This allows them to consume as much resources as they need on a given node. However, this is a not a pretty scenario for cluster administrators. With the resource quotas, admins can restrict the amount of cpu and memory resources available, on a namespace basis. Within a namespace, the resource per container or pod can be controlled by using limit ranges.
Limit Range policy can be also be used to minimum and maximum storage request per PersistentVolumeClaim as well.
If no resource requests or limits are defined by the pod/container, limit range policy can be used to do the default allocation.Read More »
A pod is a group of one or more containers in Kubernetes and it is the smallest unit of deployment for compute. The containers in a pod lives in their own cgroups but share a number of linux namespaces. Applications running in the same Pod share the same IP address and port space (network namespace), have the same hostname (UTS namespace), and can communicate using native interprocess communication channels over System V IPC or POSIX message queues (IPC namespace).
The containers in the pod are not managed individually, they are managed at pod level. The pod may also include init containers, sidecar containers and ephemeral containers, other than containers running actual application processes.Read More »
Kind is a tool which can be used for running local multi node Kubernetes clusters. Kind was primarily designed for testing Kubernetes itself and associated extensions, but may be used for local development or CI. With the Kind, you can spin up a multi node Kubernetes cluster in couple of minutes, perform your work and then wind it down. And nobody need to worry about the Bill! Starting with kind 0.11.0, Rootless Docker and Rootless Podman can be used as the node provider of kind. Its not running kubernetes in rootless mode as some component of kubernetes stack cannot run rootless yet, however it is certainly a step in that direction.Read More »
docker-compose is a popular choice to spin up applications needing multiple containers and run them. It allows to define the configuration in a simple yaml format and with few commands, you can create/manage all your application containers at once. Podman does not have a counterpart to the
docker-compose command. There is a project in the works called podman-compose, which is supposed to do the same basic thing as
However Podman uses a concept called pods. Pods are a way of grouping containers together inside their own namespace, network, and security context. You can start and stop the whole pod at once to manage your application.Read More »