What are K8s? and How to test it?

Image source: google images

What is K8s?

It’s an abbreviation which represents the 8 letter word “Kubernetes”.

Why do we need K8s?

Kubernetes is a powerful orchestrating tool for containerised applications. Orchestration means managing and automating complex system processes such as allocation of storage, network bandwidth, task management according to priority set etc.

Popular applications are usually based on microservices architecture running inside individual containers. Each service requires its own storage, bandwidth etc. So managing these containers manually can be challenging and requires 24x7 support. Here comes K8s which smoothens this process by provding a platform to automate the deployment, scaling and managing these containers.

Some common advantages of using K8s are:

1. Applications will be available even if there are failures and disruptions
2. Smart resource management and priorities can be set for each service which helps in better service availability for end users
3. Resource optimisation is another great advantage of using K8s which reduces overall cost
4. K8s provide flexibility of infra such as once setup it can work on on-premise, cloud or hybrid env.
5. Application scalability in the case demand surge

Kubernetes provides a nice abstraction of the compute infrastructure it runs on, and developers can use the same language to describe their app’s infrastructure requirements. Now, Kubernetes reads the description of the app that the developer writes. Kubernetes also collects info about the current state of the infrastructure. It uses all this info to make changes to infrastructure. When the Infrastructure looks the same as the developer’s specification, we’re done.

The app might change because people or test programs are connecting to it, so that the application might be allocating more memory, asking databases for info, processing that info, and logging about that connection. The infrastructure might change because people or infrastructure management programs are adding, changing, or removing nodes from the cluster, so maybe Kubernetes is spinning up app components, connecting those components to load balancers, and then decommissioning other app components on the nodes that are changing.

What types of Testing can be conducted for effective management and use of K8s?

Canary Testing: involve deploying new versions of applications to a Kubernetes cluster gradually, monitoring their behavior, and validating the changes before fully rolling out to production. This is even possible that we create production blue release and later we release it to production green after successful testing.

Example: canary testing in Kubernetes may involve deploying a new version of a microservice to a subset of pods or nodes, directing a portion of the traffic to the new version, and monitoring metrics such as error rates, latency, and resource utilisation to assess the impact.

Chaos Testing: Mostly conducted by DevOps team, to identify bottlenecks within application infra so as to prevent downtime which can impact our customer/user base. Replicating real events such as failures or identifying weakness within system or manually reducing resource allocation, depleting bandwith allocated can be some failure points which can impact applications performance.

Chaos testing is conducted validate application performance under such conditions and create effective solutions/configuration to minimise these risks. These can also be a part of SRE, which is known as Site Reliability Engineers.

Common terms which are used within K8s cluster management:

• Resource: Some Kubernetes object, e.g., a pod, or a persistent volume.
• Nodes: Nodes are instances of Linux running Kubelet. These are virtual machines. Nodes need a container runtime installed, like docker.
• Labels: Labels are metadata associated with some resource. Labels come in key=value pairs.
• Pods: Pods are the basic primitive for Kubernetes workloads. A pod has one or more containers in it, has a common namespace for things like network devices and processes, and probably has one or more services exposed so other pods can talk to it. Pods are intended to be short-lived.
• Services: Services define an address and port that other pods within the cluster, or other applications outside of the cluster, can establish a network connection to. This is typically a TCP port, but it could be anything. Services can be cluster-facing, external (via the load balancer, or just a port on each of the nodes).
• Volumes: Apps that need storage can be associated with a Persistent Volume. These volumes are associated with a pod by a Persistent Volume Claim, where you configure the parameters of the volume. Kubernetes creates the volume based on the declarative configuration in the claim, and the storage class referenced. Volumes can outlive pods.
• Namespaces: Kubernetes uses namespaces to organise resources it knows about. Your deployments, pods, services all belong in one namespace or another. As an example, if you install OpenEBS, all of the OpenEBS components share a single namespace.
• ConfigMaps and Secrets: Most apps require a config file of some sort. ConfigMaps and Secrets are like persistent volumes but simpler. They are intended for use for configuration files, as well as SSL certificates and the like.
• Controllers and Operators: Controllers, as mentioned above, watch and work on resources. Operators are a special case of controllers. You use the Operator Pattern to extend Kubernetes.

-x-x-

Referring this course can give you exposure to Industry standard automation framework creation and implementation of parallel testing using docker, selenium grid, github actions and CI/CD: https://topmate.io/japneet_sachdeva/873541

#japneetsachdeva