Kubernetes Archives - Page 4 of 11

Kubernetes CRI — Container Runtime Interface

Kubernetes is one of the most popular projects around container orchestration but it’s quite interesting that Kubernetes itself has no code to run or manage Linux/windows containers. So, what is running the containers within your Kubernetes pods?

Yes… Kubernetes doesn’t run your containers

It’s just an orchestration platform sitting above container runtimes. No code to run a container and to manage the container’s lifecycle on its own, instead, dockershim was implemented (in kubelet ) for talking to Docker as container runtime. I will talk about dockershim in the later section of the blog.

Also, docker has grown and matured over the last few years and has gained a stack of components like runc (open container initiative), containerd (CNCF project). OCI (est. in June,2015) splits docker into two parts:

1) to handle docker cli & processing requests and
2) to handle container running functions i.e runC.

High Level Overview — Before OCI standards

Protected EFK Stack Setup for Kubernetes

In this blog, we will see how we can deploy the Elasticsearch, Fluent-bit, and Kibana (EFK) stack on Kubernetes. EFK stack’s prime objective is to reliably and securely retrieve data from the K8s cluster in any format, as well as to facilitate anytime searching, analyzing, and visualizing of the data.

What is EFK Stack?

EFK stands for Elasticsearch, Fluent bit, and Kibana.

Elasticsearch is a scalable and distributed search engine that is commonly used to store large amounts of log data. It is a NoSQL database. Its primary function is to store and retrieve logs from fluent bit.

Fluent Bit is a logging and metrics processor and forwarder that is extremely fast, lightweight, and highly scalable. Because of its performance-oriented design, it is simple to collect events from various sources and ship them to various destinations without complexity.

On-Premise Setup of Kubernetes Cluster Components (Offline Mode) – PART 2

In the previous blog, we discussed setting up Offline Kubernetes Cluster over on-premises servers. After setting up the Kubernetes cluster we need to have some basic components to manage the orchestration and monitoring of the Kubernetes Cluster which will help Horizontal Pod Autoscaler and Vertical Pod Autoscaler to get information about CPU/Memory. Also, we have to limit access to all the components and Microservice we have set up for the SSO tool.

To begin with, we need a service mesh tool to manage the traffic flow between multiple microservices and We have many tools for this like Istio, Linkerd, Cilium Service Mesh, Consul connect, etc. Here I am considering Istio.

 Firstly, We will be talking Istio Setup over Kubernetes Cluster.

Istio is an open source service mesh that helps organizations
run distributed, microservices-based apps anywhere.
Istio enables organizations to secure, connect, and monitor
microservices, so they can modernize their enterprise apps more
swiftly and securely.
Istio allows organizations to deliver distributed applications at scale. It simplifies service-to-service network operations like traffic management, authorization, and encryption, as well as auditing and observability.

Kubernetes CSI: Container Storage Interface – Part 1

Introduction

There are different application categories in the general application world, but we usually define them in two major types, i.e., stateless and stateful applications. In Kubernetes, this distinction becomes especially important when designing and managing workloads.

To have a clearer perspective, we can say that API-based applications are generally stateless, and databases are stateful. In simple words or definition, a stateless application is an application that doesn’t save or persists the client data. On the other hand, a stateful application saves data about each client and uses it for other requests. Continue reading “Kubernetes CSI: Container Storage Interface – Part 1”

Pod Priority, Priority Class, and Preemption

While deploying the deployment manifest, we found that some of the critical pods are not getting scheduled whereas others are getting scheduled easily. Now, I wanted to make sure that the critical pod gets scheduled first over other pods. I started exploring pod scheduling and then came across one of the native solutions for Pod Scheduling using Pod Priority & Priority Class. So in this blog, we’ll talk about Priority Class & Pod Priority and how we can use them for pod scheduling.

Pod Priority

It determines the importance of a pod over another pod. It is most helpful when we need to schedule the critical pods, which are unable to schedule due to resource capacity issues.

Priority Class

It is a non-namespace object. It is used to define the priority. Priority Class objects can have any 32-bit integer value smaller than or equal to 1 billion. The higher the value, the higher will be the priority.

Pod Preemption

It allows the higher-priority pods to evict the lower-priority pods so that higher-priority pods can be scheduled, which is by default enabled when we create PriorityClass.