Understanding Kubernetes: From Basics to Cloud-Native Workflows

chapter 1

modern software architectuer, containerization andkubernetes

softwares was developed in a monoliths architecture

which are single applications, typically run independent from other applications

• thus it hard to update and to maintain

now days we have modern architecture that is constrcuted from independent building blocks called microservices

• can be independently maintained and updated
• ideally suited for cloud computing environments

now days modern applications consist of potentially tens if not thousands of building blocks, this poses the question : how we manage them, how we update them and how we deploy. how to monitor and how to maintain.

first they are deployed via containers. where wach building block is delivered in and individual container,

which includes the prequiries to run the container

another challenge is how we manage them which is the role of kubernetes that keps track of all the containers.

cloud nativeness and kubernetes, first cloud native is a way to build and deploy applications in the cloud

cloud native application are designed to be scalable.

thus kubernetes is cloud native :

• simplifies deploying and managing containers.
• enables easy scaling of application

it is an open source project by google. everyone can install it and use it.

docker and kubernetes

as we mentioned before modern softwares consites from many containers, and managing this containers is known as container orchestration and we have several tools for example :

• docker compose
• apache mesos
• docker swarm
• hashiCorp nomad
• and kubernetes

but kubernetes is the most popular with an estimated market share of 95% this is because it is available on all the cloud providers and in all environments making it the best solutions.

kubernetes for orchestration.

it solves the challenges of container orchestration and it makes it relitavely easy for example of those challenges is the scheduling and networking, where to deploy a container and how to connect them, also how to attach storage to a container.

and to do all that kubernetes communicate with Container engine, it tells it when to run, to stop and many other instructions.

the relatiionship between docker and kubernetes.

often docker is the container engine of choice, thus kubernetes nteracts with docker as a container engine to schedule and maintain containers.

to deffrentiate between docker and kuberenetes we have:

• docker is used for creating and udpating docker images.
• starting containers from such images

so kuberenetes is never used for creating those images.

kuberenetes manifests (how we interact with kuberenetes)

first kuberenetes objects (eg: containers) are described with the term manifests.

manifests are yaml files that describe which objects you want how they should be configured where they should be schedules and a lot more.

manifests are declarative, and not imperative (what not how)

kubectl is a command line to interact with kuberenetes reads your manifests sneds them to kuberenetes via its api, and kubernetes will compute what to do to achieve the state you want.

kubernetes architecture

kuberenetes is built from many elements, the most important ones from the larger to the smaller are

• clusters and controls planes
• nodes
• pods

and provides network connectivity through services.

kuberenetes cluster is a set of connected computers(or nodes), they can range from servers in a datacenter to virtual machines in the cloud.

the control plane manages these nodes, that consists of many components that can run on any node in the cluster.

a kuberenetes node typically runs linux and a container engine (docker), they are also called worker machines.

they also run the agent kubelet which ensures that containers run in so called pods.

we can add or remove nodes from our kuberenetes cluster any time.

a pod is the smallest unit that we can deploy on kuberenetes, it is a set of one or more containers.

the containers in a pod belong together logicaly, share storage and network.

pods are ephemerat :

• pods can be stopped and recreated at any point in time.
• pods can be moved to other nodes at any point in time.

(ephemeral: lasting for a very short time.)

kuberenetes services are resource for exposing network connetivity.

they are required to connect to pot from the outside, or to communicate between pods.

the reason behind this is that pods might get redeployed at any time and thus they will recieve a new IP address.

also services are not ephemeral, they offer stable network connectivity.

chapter 2

deploying a first (stateless) application

more on kubectl, it is the main command to interact with kuberenetes objects, these objects can be a pod, service…

detailed help available via command line option - -help.

manifests are declarative, typically yaml.

they have two important sections:

• metadata essential information about the object or resource.
• spec defines the specifications or desired state, of the object or resource

sections can be quite deep, depending on the resource to be deployed.

(a replica is in general an exact copy or model of something)

stateless applications, are general conceps and not specific to kuberenetes. they do not save an internal state or context of processed data.

when interrupted a new replica of the stateless app is recreated and starts operating, some examples : app that queries a database, a search app that query a full text indes, data stream app that converst temperature.

in kuberenetes stateless ap[plications translate to kuberenetes deploymement.

if take a sample we will see that the manifest consist of an api version that defines the kuberenetes api and version to be used, the kind is a deployment, spec for example defines the number of replicas, a selector and a template.

we use kubectl for creating pds and applying changes.

kuberenetes control panel will schedule the deployment on nodes, then pods created is triggered on the node.

pods get a unique but random identifie, “each pod is as good as any other”

scaling and monitoing an application (stateless) using kuberenetes

scaling means to add (scale up) or remove (scale down) resources,

a scale up is a reaction to an increasing load, a scale down is to save resources.

scaling the number of pods, is either by changing the number of replicas in th emanifest and apply it again. or to use the command kubectl scale deployment … with —replicas followed by the new number

scalability and cloud nativeness, first an application has to be designed for scalability in first, as we have seen before, for monoliths we encounter problems here.

and modern cloud native applications are designed with the goal to be easily scalable.

monitoring is observing applications in real time. enable reaction to all kind of problems,

example f moder monitopring application for kuberenetes is prometheus grafana or kubectl. however kubectl is used for basic monitoring trasks.

scaling and monitoing an application (stateful) using kuberenetes

statefull applications needs pods that belong to eachother in set, byt many work on different tasks and different data.

they are general concepts, they save some state, and when interrupted or stopped, a new replica can read the saved state and continue operating from this state. an example is a database backend like postgreSQL.

kuberenetes statefulsets is the translation in kubernetes.

statefulset is deployed similarlly to deployments kubectl apply -f with the manifest yaml file.

once deployed, they are created differently, pods are created in order not all in once, they get oredicted names, they have an identity and a state. thus different pods can perform different roles.

scaling a statefulset, they can be scaled up and down, with the same steps. also created in order and deleted in order.

for monitoring also the same thing with deployments.

deploying, scaling and monitoing kuberenetes storage

insuring data presistened in pods restarted is essental.

in kuberenetes we use presistent volumes and presistent volume claims, they are fundamental objects for storage maintained in parallel to pods.

they are mapped to pods using PVC, a mapped pv allows data presistence when the pod is stopped, killed or restarted.

they also give one of the most important feature in cloud native software design which is the seperation of storage and compute.

they are created by an kuberenetes admin, or dynamically by a regular user.

or dynamic provisioning wich happens via storage classes without human intervention.

storage classes are objects defined by kuberenetes admin, and there are many types, ssd, hdd and different backups strategies).

if in doubt we use storage classes.

manifest snippets. pod with PresistentVolume

chapter 3

networking, load balancing and security

more on labels and seletors: labels are key value pairs attached to kuberenetes objects like pods or nodes.

can be used to organize subsets of objects.

can be modified at any time.

slectors are used to indentify objects via lables

networking, services are used for network.

each pod gets its own cluster wide ip (internet), can be used for communication between pods, services are used to attach pods to and offer stable connectivity.

they can be created using manifests.

load balancer in kubernetes distributes load over pods. it avoids uneen load on resources increases efficiency and lowers reponse times and they are a special type of service.,

ingress objects are used to route http and https (traffic from outside the cluster to services in the cluster).

ingress rules define which requests are served by which service,

typically used in combination with load balancing.

kubernetes security, kuberenetes comes with its all necessary components to secure appliations running on it. we have th secrets apo for confidential objects.

tools and apis to enable encrypted network communication, and a method for authentificating users.

data pipelines on kubernetes

what are data pipelines ? data pipelines is a set process to move transform or analyze data from source to destination.

most data pipelines consist of three majure stems, extract transfer and load. what also known as ETL.

another type which is ELT, meaning extracting, and then loading and then finally the data is transformed into meaningful schema. it offers addition flexibilty

some open source tools for data pipelines, that are readily deployable on kubernetes

extract : apache NiFi, apache kafka with kafka.

transform: apache spark, apache kafka, postgreSQL

load: apache apache kafka with KSQL and postgres

for storage Minio, ceph.

MLops on kubernetes

it is a paradigm t deploy and maintain machine learning models in production.

a set f best practice workflows with focus on continuous development of such models

inspired by DevOps, so machine learning models are developed and tested in isolated experimental systems, and then deployed to production.

in production continuous monitoring,, and retraining may be triggered.

with this data scientist, data engineers and IT teams can work on deployed models synchronously and ensure model accuracy.

the MLops paradigm maps very good to kuberenetes.

tye isolated experimental systems can be realized via pods and kuberenetes storage.

monitoring production ML models via lifecycle of pods anddeployed image versions

synchronuous work on model accuracy

several frameworks, and the best know are mlflow and kubeflow.

serverless applications, KNATIVE