Abstraction & Workloads
Hello Readers, Welcome back !
Let’s continue the series of “Kubernetes For Beginners”
This is the second article of the series and I will be covering Abstraction & Workloads of K8s. I will continue to add valuable topics for the series. So watch out this space for more K8s stuff :P
For Architecture & Components of Kubernetes check the the below link.
Then meet back here to learn about Abstraction & Workloads on K8s.
Kubernetes is all about abstracting away complexity.
Why is K8s so in demand? Kubernetes (K8s) makes it easier for us to automatically scale our app, reduce downtime. We tell K8s our desired number of containers and it does the magic for us.
Cloud computing, containerization, and container orchestration are the hot trends in DevOps. Whether you’re a cloud/data/system engineer, data scientist, software developer, solution architect or product manager, it’s good to know Kubernetes basics. It helps you collaborate with others, deploy your projects & add immense value to your experience.
Deployments represent a set of multiple, identical Pods with no unique identities. A Deployment runs multiple replicas of your application and automatically replaces any instances that fail or become unresponsive. In this way, Deployments help ensure that one or more instances of your application are available to serve user requests. Deployments are managed by the Kubernetes Deployment controller.
Deployments use a Pod template, which contains a specification for its Pods. The Pod specification determines how each Pod should look like: what applications should run inside its containers, which volumes the Pods should mount, its labels, and more. When a Deployment’s Pod template is changed, new Pods are automatically created one at a time.
Groups of pods are co-located on a single “machine” (real or virtual), Each of which we call a node & Nodes are then grouped into clusters.
Those clusters are put in place by the DEPLOYMENT.
A ReplicaSet’s purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods.
The Deployment creates a ReplicaSet that will ensure your app has the desired number of Pods. ReplicaSets will create and scale Pods based on the triggers you specify in your Deployment.
A ReplicaSet is defined with fields, including a selector that specifies how to identify Pods it can acquire, a number of replicas indicating how many Pods it should be maintaining, and a pod template specifying the data of new Pods it should create to meet the number of replicas criteria. A ReplicaSet then fulfills its purpose by creating and deleting Pods as needed to reach the desired number. When a ReplicaSet needs to create new Pods, it uses its Pod template.
A Kubernetes namespace helps separate a cluster into logical units. It helps granularly organize, allocate, manage, and secure cluster resources. It provides a mechanism for isolating groups of resources within a single cluster.
A virtual cluster (a single physical cluster can run multiple virtual
ones) intended for environments with many users spread across
multiple teams or projects, for isolation of concerns. Resources inside
a namespace must be unique and cannot access resources in a
different namespace. Also, a namespace can be allocated a resource
quota to avoid consuming more than its share of the physical
cluster’s overall resources.
Default Kubernetes namespaces
Here are the four default namespaces Kubernetes creates automatically:
- default — a default space for objects that do not have a specified namespace.
- kube-system — a default space for Kubernetes system objects, such as kube-dns and kube-proxy, and add-ons providing cluster-level features, such as web UI dashboards, ingresses, and cluster-level logging.
- kube-public — a default space for resources available to all users without authentication.
- kube-node-lease — a default space for objects related to cluster scaling.
Custom Kubernetes namespaces
Admins can create as many Kubernetes namespaces as necessary to isolate workloads or resources and limit access to specific users.
Like other workload objects, a DaemonSet manages groups of replicated Pods. However, DaemonSets attempt to adhere to a one-Pod-per-node model, either across the entire cluster or a subset of nodes. As you add nodes to a node pool, DaemonSets automatically add Pods to the new nodes as needed.
DaemonSets are for continuous process. They run one Pod per Node. Each new Node added to the cluster automatically gets a Pod started by the DaemonSet. DaemonSets are useful for ongoing background tasks such as monitoring and log collection.
Some typical uses of a DaemonSet are:
- running a cluster storage daemon on every node.
- running a logs collection daemon on every node.
- running a node monitoring daemon on every node.
StatefulSet is the workload API object used to manage stateful applications.
Manages the deployment and scaling of a set of Pods, and provides guarantees about the ordering and uniqueness of these Pods.
Like a Deployment, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.
If you want to use storage volumes to provide persistence for your workload, you can use a StatefulSet as part of the solution. Although individual Pods in a StatefulSet are susceptible to failure, the persistent Pod identifiers make it easier to match existing volumes to the new Pods that replace any that have failed.
StatefulSets are valuable for applications that require one or more of the following.
- Stable, unique network identifiers.
- Stable, persistent storage.
- Ordered, graceful deployment and scaling.
- Ordered, automated rolling updates.
StatefulSets and DaemonSets are not controlled by a Deployment. Although they are at the same level of abstraction as a ReplicaSet, there is not a higher level of abstraction for them in the current API.
Follow this link if you want to know when to use StatefulSet with examples — Credits: [spacelift.io]
A Job is a supervisor for Pods that run a batch process. A Job creates Pods and ensures they do a task by tracking the number of successful Pod completions. Unlike a ReplicaSet, once the process inside the container finishes successfully, the container is not restarted. Use a Job when you want to run a process once.
A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions. When a specified number of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up the Pods it created. Suspending a Job will delete its active Pods until the Job is resumed again.
A simple case is to create one Job object in order to reliably run one Pod to completion. The Job object will start a new Pod if the first Pod fails or is deleted (for example due to a node hardware failure or a node reboot).
You can also use a Job to run multiple Pods in parallel.
If you want to run a Job at regular, specified times (e.g. hourly, daily, or monthly), create a CronJob. A CronJob is similar to a Job, but is scheduled to repeat at regular intervals or set times.
CronJobs are meant for performing regular scheduled actions such as backups, report generation, and so on. Each of those tasks should be configured to recur indefinitely (for example: once a day / week / month); you can define the point in time within that interval when the job should start.
#community #opensource #aws #K8s #EKS #docker #computing #builders
I am Kunal Shah, AWS Certified Solutions Architect, helping clients to achieve optimal solutions on the Cloud. Cloud Enabler by choice, DevOps Practitioner having 7+ Years of overall experience in the IT industry.
I love to talk about Cloud Technology, DevOps, Digital Transformation, Analytics, Infrastructure, Dev Tools, Operational efficiency, Serverless, Cost Optimization, Cloud Networking & Security.
You can reach out to me @ acloudguy.in
In next article, We will continue with “Kubernetes for Beginners” series.
Until then, Keep learning !! #K8s #OpenSource #devops
Also don’t forget to hit the clap button if you like the article :)