Networking in Kubernetes Simplified

Kubernetes Networking addresses four concerns:-

Containers within a pod use networking to communicate via loopback.
Cluster networking provides communication between different pods.
The service resources let you expose an application running in pods to be reachable from outside your cluster.
You can also use the service to publish services only for consumption inside your cluster.
Container-to-container communication on the same pod happens through localhost within the containers

Each Pod gets its own IP address, however, in a deployment, the set of pods running in one moment in time could be different from the set of Pods running that application moment later.
This leads to a problem: If some set of Pods (cal them 'backends') Provide functionality to other Pods ('Call them frontends) inside your clusters how do the frontends find out and keep track of which IP address to connect to, so that the frontend can use the backend part of the workload.
When using RC, Pods are terminated and created during scaling or replication Operations.
When using deployments, while updating the image version the pods are terminated and new pods take the Place of other pods.
Pods are very dynamic i.e. they come and go on the k8s cluster and on any of the available nodes & it would be difficult to access the pods as the Pods IP changes once it's recreated.
Service allows clients to reliably connect to the containers running in the Pod using the VIP.
Although each Pod has a unique IP address, these IPs are not exposed outside the cluster.
Services help to expose the VIP mapped to the pods & allow applications to receive traffic.
Labels are used to select which the pods to be put under a service.
Service can be exposed in different ways by specifying a type in the service spec.

Cluster IP
NodePort
Load Balancer created by cloud providers that will route external traffic to every node on the NodePort (eg-ELB on AWS)
Headless– Creates several endpoints that are used to produce DNS records. Each DNS record is bound to a Pod.

🖇️Cluster IP

🖇️NodePort

Makes a service accessible from outside the cluster.
Exposes the service on the same port of each selected node in the cluster using NAT.

Containers are short-lived in Nature.
All data stored inside a container is deleted if the container crashes. However, the kubelet will restart in a clean state, Which means that it will not have any of the old data.
To overcome this problem, Kubernetes uses volumes. A Volume is essentially a directory backed by a storage medium. The storage medium and its content are determined by the volume type.
In Kubernetes, a volume is attached to a Pod and shared among the Containers of that Pad.
The Volume has the same life span as the Pod, and it outlives the containers of the Pod this allows data to be preserved across container restarts.

Volumes Types

EmptyDir

Use this when we want to share contents between multiple containers on the same pod & not to the host machine.
An emptydir volume is first created when a pod is assigned to a node, and exist as long as that pod is running on that node.
As the name says, it is initially empty.
Containers in the pod can all read and write the same files in the emptydir volume, though that volume can be mounted at the same or different paths in each containers.
When a pod is removed from a node for any reason, the data in the emptydir is deleted forever.

HostPath

Use this when we want to access the content of a pod/container from the host machine.
A hostpath volume mounts a file or directory from the host node's filesystem into your pod.

Persistent Volume

A persistent volume (PV) is a cluster-wide resource that you can use to store data in a way that persists beyond the lifetime of a pod.
The PV is not backed by locally attached storage on a work node but by a networked storage system such as EBS or NFS or a distributed filesystem like ceph.
K8s provides APIs for users and administrators to manage and consume storage. To manage and consume storage. To manage the volume, it uses the persistent volume API resource type and to consume it, uses the persistent volume-claim API resource type.

Persistent Volume Claim

In order to use a PV you need to claim it first, using a persistent volume claim (PVC).
The PVC requests a PV with your desired specification (size, access nodes, speed etc) from Kubernetes, and once a suitable Persistent volume is found, it is bound to a Persistent Volume Claim.
After a successful bond to a pod, you can mount it as a volume.
Once a user finishes their work, the attached PersistentVolume can be released. The underlying PV can there be reclaimed and recycled for future usage.

Secrets in Kubernetes

You don't want sensitive information such as a database password or an API key kept around in clear text.
Secrets are name spaced objects, that is exist in the context of a namespace.
You can access them via a volume on an environment variable from a container running in a pod.
The secret data on nodes is stored in tmpfs volume (tmps is a filesystem that keeps all files in virtual memory.) Everything in tmpfs is temporary in the sense that no files will be created on your hard drive.
A per-secret size limit of 1 MB exists.
The API server stores secrets as plaintext in etcd. Secrets can be created 1. From a text file.

2. From a YAML file.

Namespace in Kubernetes

A namespace is a group of related elements that each have a unique name or identifier. A namespace is used to uniquely identify one or more names from other similar names of different objects, groups, or the namespace in general.
A mechanism to attach authorization and policy to a subsection of the cluster.

Pod Lifecycle

Continue experimenting, learning, and building on Kubernetes, and you'll be well-equipped to tackle complex cloud-native challenges.

Thank you🙏

Keep Learning..