I know what is the advantages of pod over the container it is there in the Kubernetes documentation but still unable to understand the same tasks and actions can be performed with container too then why we need pods in Kubernetes?
The K8s documentation describes containers and pods pretty well. But in essence:
A pod in the K8s context
A group of containers
Containers share networking. For example, the same IP address
Typically multi-container pods are used when you need a sidecar container. For example:
A proxy process to your main container.
A debug container with utilities.
A process that always needs to run together with your app.
A container that does some sort of networking changes that your app needs.
Allows you to set up a securityContext for all the pods in the container.
Allows you to set up a Disruption Budget policy to prevent downtime for example.
Allows you to use higher-level Kubernetes abstractions like Deployments, StatefulSets and Jobs.
Allows you to set Pod presets so that a pattern can be reused.
A container in the K8s context
A lower-level abstraction from a pod
Allows you to specify the image
Allows you to specify resources (mem/cpu)
Allows you to setup Liveness, Startup, and Readiness Probes.
Allows you to set up a securityContext just for the container individually
Related
Why does docker kubernetes duplicate pods? I see on the dashboard some pods with k8s and with k8s_POD even my deployments.yaml has replica=1
Does anyone have any ideas on this?
All containers: in a kubernetes Pod share the same cluster's Pod IP address, and for each one of them 127.0.0.1 is the same as the others. The way that magic happens is via that k8s_POD_ container, which is the one running the pause image and is the only container which is assigned a kubernetes Pod IP via CNI. All containers in that Pod then use its network_namespace(7) to send and receive traffic within the cluster. That's also why one can restart a container without it losing the IP address, unlike deleting a Pod which gets a fresh one
To the best of my knowledge, those sandbox containers can exist even without any of the other containers in cases where the main container workloads cannot start due to pending volumes (or other resources, such a GPUs), since the CNI allocation process happens very early in the Pod lifecycle
I could have sworn it was in an existing question but I wasn't able to readily find it
What is the nature of the relationship between Docker and Kubernetes? Is it safe to assume that ALL Docker operations done within a Pod will treat the Pod as if it is a normal host machine?
For example, if I were to use the Python Docker SDK, attach to the /var/run/docker.sock, and create a volume, will this volume only exist within the Pod?
My main concern is that I know a Pod is virtualized, thus may not play nicely if I dig a little too deep via other virtualization tools like Docker.
It's important to understand what the responsibility of each of these concepts is.
A Docker container is in essence a boundary between the host OS and guest OS, that allows for a process to run in isolation (docs).
Kubernetes is an orchestration platform for running such containers (docs).
Finally a Pod is a kubernetes object that describes how a docker container is to be run (docs).
With that knowledge we can answer some of your questions;
What is the nature of the relationship between Docker and Kubernetes?
Kubernetes can run docker containers like your computer can, but it's optimised for this specific goal. Kubernetes is also an abstraction (or orchestration) layer, handling resources like network capability, disk space, and cpu cycles for you.
Is it safe to assume that ALL Docker operations done within a Pod will treat the Pod as if it is a normal host machine?
A Pod is not a host in any way. It's merely a description of how a docker container (or multiple) should run. Any resulting containers are running in the virtual space that is created by the kubernetes Nodes.
For example, if I were to use the Python Docker SDK, attach to the /var/run/docker.sock, and create a volume, will this volume only exist within the Pod?
This is something you can do on your local machine, and while technically you could do this on your Node as well, it's not a common use case.
Note that a docker container is isolated from any external factors like a mount or a network socket (which only happen at runtime, and don't change the state of the container itself). You can however configure a container (using a Pod object) to recreate the same conditions on your cluster.
If Kubernetes is running Docker (it's not guaranteed to) then that /var/run/docker.sock will be the host's Docker socket; there is not an additional layer of virtualization.
You shouldn't try to use Docker primitives in an application running in Kubernetes. The approach you describe can lead to data loss, even, if you try to create a Docker-native volume on a node but then a cluster autoscaler or some other task destroys the node. If you need to create storage or additional containers, you can use the Kubernetes API to create PersistentVolumeClaims, Jobs, and other Kubernetes-managed objects.
I am currently working with a Hyperledger Fabric v1.4 deployment over k8s. The chaincode containers that are generated are basically create by the container running within the peer pods and k8s as such has no knowledge and control of the chaincode containers. In such a scenario where there is a Docker container running along with k8s and k8s has no knowledge of a particular docker container, is it possible for the Docker container to in some way gain access to the k8s master API and gain access to the whole k8s cluster consequently?
My intention with asking this question is to figure out if there is a way to use an container external to any pods in k8s, to cause any undesirable impact to the k8s cluster by gaining unauthorized access to k8s. The chaincode container that I talked about, is created using a trusted template image and the only possible malicious component in the container is a single golang, java or nodejs script that is provided by the user. So my real question here is, "Is it possible using these user scripts gain unauthorized access to the k8s cluster?" And I am primarily focusing on a manager k8s service like Azure Kubernetes Service.
Your question totally changed the meaning so I'll try to rewrite the answer.
You have to remember that the pod you are running the code on by default is limited to just the namespace it's running on. If you didn't gave it any higher privileges. Also the code is not running as root.
You can read about Pod Security Policies and Configure a Security Context for a Pod or Container.
TLDR.
As long as you don't give it any special privileges or rights it should be fairly save for your cluster.
How does kubernetes pod gets IP instead of container instead of it as CNI plugin works at container level?
How all containers of same pod share same network stack?
Containers use a feature from the kernel called virtual network interface, the virtual network Interface( lets name it veth0) is created and then assigned to a namespace, when a container is created, it is also assigned to a namespace, when multiple containers are created within the same namespace, only a single network interface veth0 will be created.
A POD is just the term used to specify a set of resources and features, one of them is the namespace and the containers running in it.
When you say the POD get an IP, what actually get the ip is the veth0 interface, container apps see the veth0 the same way applications outside a container see a single physical network card on a server.
CNI is just the technical specification on how it should work to make multiple network plugins work without changes to the platform. The process above should be the same to all network plugins.
There is a nice explanation in this blog post
its the kubeproxy that makes everything work. one pod has one proxy which translates all the ports over one IP for the remaining containers. only in specific cases it is said that you want to have multiple containers in the same pod. its not preferred but its possible. this is why they call it "tightly" coupled. please refer to: https://kubernetes.io/docs/concepts/cluster-administration/proxies/
Firstly, let's dig deeper into the CNI aspect. In production systems, workload/pod (workload can be thought of as one or many containerized applications used to fulfill a certain function) network isolation is a first class security requirement. Moreover, depending on how the infrastructure is set up, the routing plane might also need to be a attribute of either the workload (kubectl proxy), or the host-level proxy (kube proxy), or the central routing plane (apiserver proxy) that the host-level proxy exposes a gateway for.
For both service discovery, and actually sending requests from a workload/pod, you don't want individual application developers to talk to the apiserver proxy, since it may incur overhead. Instead you want them to communicate with other applications via either the kubectl or kube proxy, with those layers being responsible for knowing when and how to communicate with the apiserver plane.
Therefore, when spinning up a new workload, the kubelet can be passed --network-plugin=cni and a path to a configuration telling kubelet how to set up the virtual network interface for this workload/pod.
For example, if you dont want your application containers in pod to be able to talk to host-level kube proxy directly, since you want to do some infrastructure specific monitoring, your CNI and workload configuration would be:
monitoring at outermost container
outermost container creates virtual network interface for every other container in pod
outermost container is on bridge interface (also a private virtual network interface) that can talk to kube proxy on host
The IP that the pod gets is to allow other workloads to send bytes to this pod, via its bridge interface - since fundamentally, other people should be talking to the pod, not individual work units inside the pod.
There is a special container called 'pause container' that holds the network namespace for the pod. It does not do anything and its container process just goes into sleep.
Kubernetes creates one pause container for each pod, to acquire the respective pod's IP address and set up the network namespace for all other containers that are part of specific pod. All containers in a pod can reach each other using localhost.
This means that your 'application' container can die, and come back to life, and all of the network setup will still be intact.
In dockers, I had two containers Mosquitto abd userInfo
userInfo is a container which performs some logic and then send the result to mosquitto container. Mosquitto container then use this information to send it to IOT hub. To start these containers in Docker, I created a network and started both the container in the same network. So I can easily use the hostname of mosquitto container inside userinfo container to send data. I need to do this same in kubernetes.
So in kubernetes, what I did, I deployed the Mosquitto so its POD was created then I created its service and use it inside the userInfo pod to send data to mosquitto. But this is not working.
I created the service by using
kubectl expose deployment mosquitto
I need to send data of userInfo to Mosquitto.
How can I achieve this.?
Do I need to create network as I was doing in dockers or is there any other way.?
I also tried creating a pod with two containers i.e. mosquitto & userInfo, but this was also not working.
Thanks
A Kubernetes pod may contain multiple containers. People generally run multiple containers in a pod when the two containers are tightly coupled, and it sounds like this is what you're looking for. These containers are guaranteed to be hosted on the same machine (they can contact each other via localhost), share the same port space, and can also use the same volumes.
https://kubernetes.io/docs/concepts/workloads/pods/pod/#what-is-a-pod
Two containers same POD
If you are interested in the communication between two containers belonging to the same POD there is the guide from the official documentation showing how to achieve this through shared volumes.
The primary reason that Pods can have multiple containers is to support helper applications that assist a primary application. Typical examples of helper applications are data pullers, data pushers, and proxies. Helper and primary applications often need to communicate with each other. Typically this is done through a shared filesystem, as shown in this exercise, or through the loopback network interface, localhost.
Try to avoid to place two container in the same POD if you do not need it. Additional information can be found here: Multi-container pods and container communication in Kubernetes.
Two containers two POD
In this case (you can do the same also for the previous case) the best way to proceed is to expose a through a service the listening process of the container.
In this way you will be able to rely always on the very same IP or domain name (that you will be able to resolve merely internally) and port.
For example, if you have a Service called "my-service" in Kubernetes Namespace "my-ns" a DNS record for "my-service.my-ns" is created.
The network part is managed by Kubernetes so you will not need to do anything(in the basic configurations), merely when creating the service to instruct which is the target port of the container and the port that the client should use and the mapping is automatic.
Then once you exposed a port and an IP how you implement the communication and the datatransfer is no longer a Kubernetes question. You can implement it thorough a web server having static contents, through FTP, having a script sending SCP commands, basically there are infinite ways to do it.