Kubernetes on Alperen Doc

kubernetes-minikube

Mon, 01 Jan 0001 00:00:00 +0000

Minikube#

During this blog, we’ll be using Minikube to practice with Kubernetes. In production, you probably wouldn’t use Minikube, you would use a cluster of servers, probably in the cloud. That’s expensive! Minikube is a fantastic tool that allows you to run a single-node Kubernetes cluster on your local machine.

Kubectl#

The Kubernetes command-line tool, kubectl, allows you to run commands against Kubernetes clusters. It’s a client that communicates with a Kubernetes API server.

kubernetes-pods-minikube

Mon, 01 Jan 0001 00:00:00 +0000

Pods#

“Pods are the smallest deployable units of computing that you can create and manage in Kubernetes.”

– The Kubernetes team

A Pod is the smallest and simplest unit in the Kubernetes object model that you create or deploy. It represents one (or sometimes more) running container(s) in a cluster. In a simple web application, you might have one single pod: the web server. As traffic grows, you might deploy that same code to multiple pods to handle the increased load. Several pods, one codebase. In a more complex backend system, you might have several pods for the web server and several pods that handle video processing. Multiple pods, multiple codebases.

kubernetes-deployments-minikube

Mon, 01 Jan 0001 00:00:00 +0000

Deployments#

A Deployment provides declarative updates for Pods and ReplicaSets.

You describe your desired state in a Deployment, and the Deployment Controller’s job is to make the current state match the desired state. You declare your hopes and dreams, and it’s Kubernetes’ job to make them come true.

Why Deleting a Pod Doesn’t Feel Like a Deletion#

Remember when we had you delete a pod, only to see that a new pod was created in its place? It’s kinda like chopping heads off of a hydra.

kubernetes-probes

Mon, 01 Jan 0001 00:00:00 +0000

Probes#

We’ve created pods, watched them get replaced when we deleted them, and even debugged a CrashLoopBackOff or two. But here’s the uncomfortable truth: Running does not mean healthy. A pod can be “Running” while the app inside is completely broken - a web server listening on the wrong port, an API that hangs on every request, or a process that deadlocked mid-chat.

Probes are Kubernetes’ way of asking your application: “are you actually okay?” They come in three flavors:

kubernetes-deployment-rollouts

Mon, 01 Jan 0001 00:00:00 +0000

Rolling Updates#

In the deployments chapter we saw that a Deployment keeps the right number of pods alive no matter what. And in probes we made those pods smart enough to fail health checks before they take traffic. Now the obvious question: what happens when we want to change the app itself - a new image, a new env var, a bug fix?

Remember the hydra? A rolling update is the same trick applied to software versions: we grow new heads while chopping off the old ones. Users see one consistent service the whole time, and if the new heads turn out to be poisonous, we grow the old ones back.

kubernetes-yaml-configurations

Mon, 01 Jan 0001 00:00:00 +0000

YAML Config#

Kubernetes resources are primarily configured using YAML files. We’ve used the kubectl edit command to edit resources in the cluster on-demand, but let’s inspect our deployment’s YAML file a bit more closely.

Assignment#

First, download a copy of your deployment’s YAML file and save it in your current directory:

kubectl get deployment synergychat-web -o yaml > web-deployment.yaml

Then open it in your text editor. There are 5 top-level fields in the file:

kubernetes-secrets

Mon, 01 Jan 0001 00:00:00 +0000

Secrets#

In the YAML config chapter we saw that ConfigMaps are a great way to manage innocent environment variables - ports, URLs, feature flags. But we also learned that ConfigMaps are not encrypted, and anyone with access to the cluster can read them.

Secrets are the Kubernetes object designed for sensitive data: passwords, tokens, and keys. Functionally, they look a lot like ConfigMaps. The differences are:

Values are stored base64-encoded in the object
Access can be restricted with RBAC (who can read which secrets)
etcd can be configured to encrypt secret data at rest

Creating a Secret#

The imperative way:

kubernetes-rbac

Mon, 01 Jan 0001 00:00:00 +0000

RBAC#

In the secrets chapter we said that secret data “can be restricted with RBAC”. That was a promise we haven’t paid off yet. Let’s pay it off.

RBAC - Role Based Access Control - answers one question: who is allowed to do what to which objects. It’s the bouncer at the club door. Everyone with a kubeconfig on your laptop is a cluster-admin, which is why it never came up until now. But the moment you hand a namespace to a team, or give an app a token, the bouncer starts working.

kubernetes-jobs-cronjobs

Mon, 01 Jan 0001 00:00:00 +0000

Jobs#

Everything we’ve deployed so far has been a long-running service. A deployment promises “keep N replicas running at all times”. But a lot of real work is the opposite: run once, finish, exit. Think database backups, schema migrations, or batch processing.

A Job creates one or more pods and keeps retrying them until the specified number of pods successfully terminate.

	Deployment	Job
Amaç	Servis sürekli çalışsın	İş tamamlanana kadar çalışsın
Pod durumu	`Running` (olması beklenen)	`Completed` (başarı sinyali)
Çalışma biçimi	Sonsuz döngü	Bitince exit code ile biter
Örnek	web, api, crawler	migration, backup, batch

A minimal job looks like this:

kubernetes-services

Mon, 01 Jan 0001 00:00:00 +0000

Services#

We’ve spun up pods and connected to them individually, but that’s frankly not super useful if we want to distribute real traffic across those pods. That’s where services come in.

Services provide a stable endpoint for pods. They are an abstraction used to provide a stable endpoint and load balance traffic across a group of Pods. By “stable endpoint”, I just mean that the service will always be available at a given URL, even if the pod is destroyed and recreated.

kubernetes-ingress

Mon, 01 Jan 0001 00:00:00 +0000

Ingress#

In the services chapter we promised to talk more about exposing things to the outside world. Time to pay that off too.

A LoadBalancer service gives every app its own cloud load balancer and its own public IP. That’s fine when you have one app. With three apps, three IPs, three DNS records, three TLS certificates, three bills. What we actually want is one entry point that routes chat.example.com to the web app and api.example.com to the API - and gives us HTTPS while it’s at it.

kubernetes-gateway-minikube

Mon, 01 Jan 0001 00:00:00 +0000

Gateway#

A Gateway resource exposes services to the outside world and is used often in production environments. From the docs:

A Gateway describes an instance of traffic handling infrastructure. It defines a network endpoint that can be used for processing traffic, i.e. filtering, balancing, splitting, etc. for backends such as a Service. For example, a Gateway may represent a cloud load balancer or an in-cluster proxy server that is configured to accept HTTP traffic.

kubernetes-namespaces

Mon, 01 Jan 0001 00:00:00 +0000

Namespaces#

To quote the Zen of Python:

Namespaces are one honking great idea – let’s do more of those!

Namespaces are a way to isolate cluster resources into groups. They’re a bit like directories on your computer, but instead of containing files, they contain Kubernetes objects. As you’ve already learned, every resource in Kubernetes has a name. Some of our names include:

synergychat-api-configmap
api-service
api-deployment
web-deployment
…

You can only use a name once. It is a unique identifier. That’s how kubectl apply knows when it should create a new resource and when it should update an existing one. Namespaces allow us to use the same name for different resources, as long as they’re in different namespaces.

kubernetes-dns-coredns

Mon, 01 Jan 0001 00:00:00 +0000

Cluster DNS#

In the namespaces chapter we casually dropped the magic formula <service>.<namespace>.svc.cluster.local and told you to wire CRAWLER_BASE_URL with it. It worked, which means something in the cluster is doing name resolution for us. What is it?

Kubernetes runs a DNS server inside the cluster and automatically creates a record for every Service. That’s why pods can find each other by name instead of by IP - and why pod IPs (which are ephemeral and worthless to hardcode) don’t scare anyone.

kubernetes-scaling-vertical

Mon, 01 Jan 0001 00:00:00 +0000

Top#

We’ve already learned how to look at logs for k8s pods, but sometimes that’s not enough when it comes to debugging. Sometimes we want to know about the resources that a pod is using.

To get metrics working, we need to enable the metrics-server addon. Run:

minikube addons enable metrics-server

Take a look inside the kube-system namespace:

kubectl -n kube-system get pod

You should see a new “metrics-server” pod. It might take a couple of minutes to get started, but once that pod is ready, you should be able to run:

kubernetes-scaling-horizontal

Mon, 01 Jan 0001 00:00:00 +0000

Horizontal Pod Autoscaling (HPA)#

A Horizontal Pod Autoscaler can automatically scale the number of Pods in a Deployment based on observed CPU utilization or other custom metrics. It’s very common in a Kubernetes environment to have a low number of pods in a deployment, and then scale up the number of pods automatically as CPU usage increases.

Assignment#

First, delete the replicas: 1 line from the synergychat-testcpu deployment. This will allow our new autoscaler to have full control over the number of pods.

kubernetes-storage

Mon, 01 Jan 0001 00:00:00 +0000

Storage in Kubernetes#

By default, containers running in pods on Kubernetes have access to the filesystem, but as we’re about to find out, there are some big limitations to this.

example#

The api application in SynergyChat can be configured to save its data (the messages) to a file on the filesystem. That way, even if the program is restarted, the messages will still be there.

Update the api service’s ConfigMap to include a new environment variable:

kubernetes-persistent-volumes

Mon, 01 Jan 0001 00:00:00 +0000

Persistent Volumes (PV)#

Instead of simply adding a volume to a deployment, a persistent volume is a cluster-level resource that is created separately from the pod and then attached to the pod. It’s similar to a ConfigMap in that way.

PVs can be created statically or dynamically.

Static PVs are created manually by a cluster admin
Dynamic PVs are created automatically when a pod requests a volume that doesn’t exist yet

Generally speaking, and especially in the cloud-native world, we want to use dynamic PVs. It’s less work and more flexible.

kubernetes-storage-classes

Mon, 01 Jan 0001 00:00:00 +0000

StorageClasses#

In the persistent volumes chapter we created a PVC and a PV just… appeared. Nobody wrote a PersistentVolume object. So who decided its size, its disk type, and what happens when we delete it?

That somebody is a StorageClass. Think of it as a template for dynamically provisioned volumes: a name a PVC can ask for, plus the recipe the cluster uses to go create a real disk.

kubectl get storageclass

Minikube has one called standard (usually marked default). Longhorn, if you installed the longhorn chapter, adds another. The (default) annotation is what makes storageClassName optional in a PVC - leave it out and you get that one.

kubernetes-statefulsets

Mon, 01 Jan 0001 00:00:00 +0000

StatefulSets#

In storage we learned that the filesystem inside a pod is ephemeral, and in persistent volumes we attached a PVC to keep data alive across pod restarts. But there’s one piece of the puzzle missing.

Deployments treat all their pods as identical, interchangeable clones. synergychat-web-679cbcc6cd-cq6vx could die at any moment and a fresh synergychat-web-679cbcc6cd-x9k2f takes its place - nobody cares which is which. That’s perfect for web servers and APIs.

Databases are different. Each instance needs:

kubernetes-nodes-basic

Mon, 01 Jan 0001 00:00:00 +0000

Nodes#

We’ve talked about how in a production environment, you’ll have multiple nodes in your cluster. For this course, we’ve been using a single node cluster with minikube. The nice thing about Kubernetes is that almost everything you do with it is abstracted away from the underlying infrastructure with the kubectl CLI.

All the commands we’ve been using locally will work the same way on a production cluster.

Ways to Deploy to Production#

There are several popular ways to deploy a Kubernetes cluster to production: