K8s Architecture

Introduction

As the microservice trend continues to rise, resulting in increased usage of containers, the demand for efficient management of these numerous containers across multiple environments. This is where Kubernetes, often abbreviated as K8s, comes in.

Kubernetes is an open-source container orchestration tool, developed by Google. That aids in managing containerized applications in different deployment environments like Physical Machines, Virtual Machines or Cloud Environments.

K8s is designed to provide a platform that is highly available, flexible, reliable, and scalable to run container workloads. This article will delve into the fundamental components and concepts of Kubernetes architecture. Furthermore, I will implement the demo using kubectl and GKE.

Master Node

The master node (also known as the Control plane) is responsible for the management of the Kubernetes cluster. It is the entry point for all administrative tasks. There are four main processes that run on every master node:

API Server: It's the front-end of the control plane. Kube-apiserver exposes the Kubernetes API, which is used by external users to perform management operations on the cluster.

Controller Manager: This component manages controllers, which regulate the state of the system, such as replication controllers, endpoints controllers, and namespace controllers.

Scheduler: Responsible for the distribution of tasks or workloads across worker nodes. It decides where to place pods based on factors like resource availability and constraints.

etcd: etcd is a consistent and highly-available key-value store used as Kubernetes' backing store for all cluster data. It keeps full control over the cluster state, managing the configuration data of the Kubernetes cluster and representing the overall "source of truth" for the cluster. If the etcd service fails on a node, Kubernetes will automatically elect a new master node.

These processes communicate with one another to collectively manage the state of the Kubernetes cluster.

Worker Node

Worker nodes contain the necessary tools to run or manage containers. Each worker node runs two processes:

Kubelet: This process communicates with the master node to ensure that containers in a pod are running and healthy.

Kube-proxy: Kube-proxy handles individual host subnetting and makes sure services are available to other components in the cluster by managing network rules.

Pod

In the Kubernetes context, a Pod is the smallest unit of computing that you can deploy inside a cluster. It is a group of one or more containers with shared storage and network, along with a specification for how to run the containers.

Service

A Kubernetes Service is an abstraction layer that defines a logical set of pods and a policy for accessing them. Services ensure that no matter which pod receives a request, it gets routed to the appropriate pod. They provide network connectivity for pods and enable load balancing and service discovery.

Storage

Kubernetes allows you to automatically mount a storage system of your choice. This storage may come from local sources, public cloud providers such as GCP or AWS, or network storage systems like NFS, iSCSI, Gluster, or Ceph. Kubernetes abstracts the underlying storage details and makes it accessible to your pods as persistent volumes.

Deployment

A Deployment is a Kubernetes controller that provides declarative updates to applications. It allows you to describe an application's lifecycle, from creation to updates and deletion. Deployments are typically used for stateless services where you want to deploy servers and scale them to handle varying loads.

Demo K8s on GCP

K8s was developed by Google. Therefore, there's no better way to illustrate its implementation than by utilizing the Google Kubernetes Engine (GKE) on Google Cloud Platform (GCP).

1. Launch Cloud Shell

Go to the Google Cloud console -> Click the Activate Cloud Shell button.

Before you run commands, set the default project in the Google Cloud CLI using the following command:

gcloud config set project PROJECT_ID

2. Create a GKE cluster

gcloud container clusters create-auto hello-cluster \

    --region "asia-southeast1" \

--release-channel "regular"

3. Get authentication credentials for the cluster

After creating your cluster, you need to get authentication credentials to interact with the cluster. This command configures kubectl to use the cluster you created.

gcloud container clusters get-credentials hello-cluster \

  --location asia-southeast1

4. Create deployment configuration

You'll need Kubernetes configuration files to deploy your app. Here are the YAML files.

This Deployment configuration named "hello-deployment" is running within the default namespace and is labeled as "nodejs-app". It creates and manages 2 replicas. These replicas are using the "cucongcan/echo-server:latest" image. The label "app: nodejs-app" is used to identify the Pods that the Deployment manages.

---

apiVersion: "apps/v1"

kind: "Deployment"

metadata:

  name: "hello-deployment"

  namespace: "default"

  labels:

    app: "nodejs-app"

spec:

  replicas: 2

  selector:

    matchLabels:

      app: "nodejs-app"

  template:

    metadata:

      labels:

        app: "nodejs-app"

    spec:

      containers:

        - name: nodejs-app-container

          image: cucongcan/echo-server:latest

A Service named "nodeapp-service-lb" is created which exposes your application on a network. This Service is of type "LoadBalancer" which means it will distribute network traffic to all the Pods of your deployment running in the cluster. The Service routes traffic to Pods having the label "app: nodejs-app".

---

apiVersion: v1

kind: Service

metadata:

  name: nodejs-app-lbservice

spec:

  type: LoadBalancer

  selector:

    app: nodejs-app

  ports:

    - protocol: "TCP"

      port: 80

      targetPort: 80

"HorizontalPodAutoscaler" (HPA) named "hello-deployment-hpa-1" is designed to automatically scale the number of pods in a Deployment based on observed CPU utilization. Again, it's running in the default namespace and is labeled as "nodejs-app". The HPA is targeting the "hello-deployment" Deployment. It maintains a minimum of 2 replicas and can scale up to a maximum of 5 replicas, depending upon the load.

---

apiVersion: "autoscaling/v2"

kind: "HorizontalPodAutoscaler"

metadata:

  name: "hello-deployment-hpa-1"

  namespace: "default"

  labels:

    app: "nodejs-app"

spec:

  scaleTargetRef:

    kind: "Deployment"

    name: "hello-deployment"

    apiVersion: "apps/v1"

  minReplicas: 2

  maxReplicas: 5

  metrics:

    - type: "Resource"

      resource:

        name: "cpu"

        target:

          type: "Utilization"

          averageUtilization: 80

5. Deploy an application to the cluster

kubectl apply -f deploy.yml

6. Inspect and view the application

kubectl get pods

kubectl get service nodejs-app-lbservice

Open the app by using Load-balancer External-IP in the browser: http://${LB-EXTERNAL-IP}

1. Clean up

kubectl delete service hello-server

gcloud container clusters delete hello-cluster \

  --location asia-southeast1

Logging

Container logs

Kubernetes captures logs from each container in a running Pod. To fetch the logs, use the kubectl logs command:

cancc@cloudshell:~ (k8sproject-402813)$ kubectl get pod

NAME                                READY   STATUS    RESTARTS   AGE

hello-deployment-68bc94dfff-92956   1/1     Running   0          25h

cancc@cloudshell:~ (k8sproject-402813)$ kubectl logs hello-deployment-68bc94dfff-92956

Cloud Logging

By default, GKE clusters are integrated with Cloud Logging (and Monitoring). When you create a GKE cluster, both Monitoring and Cloud Logging are enabled by default. That means you get a monitoring dashboard specifically tailored for Kubernetes and your logs are sent to Cloud Logging’s dedicated, persistent datastore, and indexed for both searches and visualization in the Cloud Logs Viewer. 

GKE deploys a per-node logging agent that reads container logs, adds helpful metadata, and then sends the logs to the logs router, which sends the logs to Cloud Logging.

Where to find your logs?

Cloud Logging console – Select the Kubernetes resources such as cluster, node, namespace, pod or container logs.

GKE console – Select the Kubernetes resources listed in Workloads, and then the Container or Audit Logs links.

gcloud command line tool.

Conclusion

In this article, we explored the key components of the Kubernetes architecture. A practical demo using kubectl and Google Kubernetes Engine (GKE) offered real-world insights into deploying applications and viewing logs within the Kubernetes environment.

Keep learning, and happy Kubernetes exploration!

Refer

https://kubernetes.io/docs/concepts/architecture/

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

https://cloud.google.com/kubernetes-engine/docs/deploy-app-cluster

https://cloud.google.com/blog/products/management-tools/using-logging-your-apps-running-kubernetes-engine

Back to index