DEV Community: Kubernetes Community Days Chennai

Updates about KCD Chennai 2024

KCD Chennai — Tue, 08 Oct 2024 06:13:25 +0000

Hey KCD Chennai Community! 👋

Many of you have been asking about KCD Chennai 2024. There's been some exciting developments in the KCD world this year! 🎉

Firstly, Cloud Native Computing Foundation (CNCF) has implemented a new guideline for KCD events within the same country/region. To ensure a vibrant ecosystem and avoid scheduling conflicts, KCDs need to be at least 2 months apart, and not held within 2 months of other major CNCF/LF events. 🥇

2024 has seen the incredible launch of brand new KCDs in India! KCD Kerala, KCD Pune and KCD Hyderabad. 🎈

Additionally, India is hosting its very first dedicated KubeCon event in New Delhi from December 10th-12th, 2024! This flagship event deserves the spotlight, so we've made the difficult decision to forgo KCD Chennai 2024. ✨

This decision allows other KCD communities in India to flourish and grow, fostering collaboration and knowledge sharing – the core values of open source! 🦄

Open-source communities thrive on the principles of openness, collaboration, and cooperation. These values are fundamental to nurturing innovation, knowledge sharing and community growth. CNCF and hence the KCD Chennai community exemplifies these principles, creating a space where other communities thrive as well. Together, we're stronger! 🤝

We'll keep you updated on KCD Chennai 2025 soon. Stay tuned! 🔊

Storing and Searching TeraByte Scale logs in SnappyFlow with Secondary Storage

KCD Chennai — Wed, 19 Jul 2023 07:22:18 +0000

The premise

Log management in modern organizations

In most enterprises today, big, and small, it is not uncommon to have a tech stack comprising 50 or more different technologies across their applications and infrastructure, and this number is likely to increase as companies embrace microservices, multi/hybrid clouds, and containerization.

All these individual components generate logs, and lots of the. These logs serve as invaluable sources of information, providing insights into the health of individual components, transaction details, timestamps, and other critical data. By analyzing these logs, SREs and DevOps engineers can gain a comprehensive understanding of their systems, diagnose issues promptly, and optimize performance. Development teams rely on these logs to understand and address issues before they affect customers and businesses.

Each log entry represents a specific event that happened at a precise moment in time, allowing for accurate tracking and analysis of system behavior. For instance, when a fault occurs, logs enable developers to identify errors and look for related logs, system performance metrics, and application traces and drill down to the exact line of code to troubleshoot.

Challenges in managing Terabyte and Petabyte scale logs

As more logs get generated, it quickly becomes a “storage” and “search” problem. Although individual logs are tiny – just a few Bytes, the cumulative volume of logs across your stack, multiplied over several days can quickly reach Terabytes or Petabytes. Efficient search and storage mechanisms become crucial for developers and engineers in handling this large log volume.

Log retention, defines how long the logs are stored and in turn determines the total log volume. Factors such as security, regulatory compliances and cost have to be taken into account, to arrive at an optimal log retention period. Striking a balance between cost-effectiveness and fulfilling operational, analytical, and regulatory needs is key to optimizing log storage.

However, retaining logs for extended periods, spanning months or years, introduces complications. The common approach of compressing and storing logs in cost-effective solutions like AWS Glacier hinders real-time log retrieval and search capabilities. While suitable for auditing, this method limits developers' ability to efficiently analyze and troubleshoot logs in a timely manner.

To overcome these limitations, engineers require a solution that allows quick access to archived logs without sacrificing real-time search functionality. This ensures developers can effectively analyze logs, even in long-term retention scenarios, enabling timely analysis and troubleshooting.

Introducing SnappyFlow's Secondary storage feature

SnappyFlow provides an elegant solution to ingest, store and search large volumes of logs for extended periods of time using what we call the “Secondary Storage” feature. Secondary Storage allows massive streams of logs to be ingested and stored in a cost-efficient manner without losing the ability to easily search logs.

So, is there a Primary Storage?

Yes. By default, all logs sent to SnappyFlow are stored in a “Primary Storage”. Think of Primary storage as fast and responsive storage system capable of handling a large volume of searches at lightning-fast speeds. These are typically fast SSD-type storages and are as expected, expensive.

How does Secondary Storage work?

Different log sources can be configured to send logs to Primary Storage, Secondary Storage, or both.

This is available under Log Management > Manage Logs. In the screenshot below, you can see a list of rules for the project apmmanager-opensearch. Note that in this example, you are looking at project-level rules. Similar views are available at Application and Profile levels.

Project level view of Secondary Storage Rules for the project apmmanager-opensearch

Application level view of Secondary Storage Rules for the project apmmanager-k8

The default rules are set to send all logs to both Primary and Secondary storage with a retention period of 7 days and 30 days respectively. New rules can be added using the Add Rule button and it takes a couple of minutes for these rules to get activated.

Once the rules are applied, these can be viewed under Applied Rules

Adding a new secondary storage rule for server logs

Searching logs in Secondary Storage

Search for logs in secondary storage is available under the respective applications. To access go to any application and select Log Management > Secondary Storage

In the Secondary Storage page, live search is available for data from the last 30 minutes. Logs can be filtered using the log type or using simple search strings. The Search History tab allows you to create search jobs and these jobs run in the background. Once a search job is completed, the search results can be accessed instantly any time.

Live search and search history for secondary storage logs

Limitations

All logs in secondary storage can be searched in real-time (only the last 30 minutes) or search jobs can be set up and the indexed results can be accessed instantly.
It is not possible to create dashboard out of logs in secondary storage.
Secondary storage logs are not part of the usual log workflow i.e trace to log

An illustration of the benefit of using secondary storage for log management

Secondary storage can compress logs by upto 40 times the original size and can provide significant cost benefits. Consider a medium-sized SnappyFlow deployment with an average daily ingest volume of 1 TB with a retention of 15 days. At any given time, 15 TB of primary storage is required simply to hold this data. If we were to use Secondary storage to move say 60% of all the logs, we would need to incrementally store only 400 GB of logs on a daily basis and this works out to 6 TB of primary storage.

At the time of writing, the cost of EBS storage on AWS is

15 TB, GP3 - $2001/mo

6 TB, GBP - $800/mo

Here, there is a straightforward reduction in monthly costs of $1200 simply by routing 60% of logs to Secondary storage. Do note that there will be an additional cost of storing data in Secondary Storage but this is significantly lower as we will be using an object-based storage service like S3.

With a compression factor of 40x and a log retention period of 60 days, total log volume in secondary storage will be (1 TB/day * 60% * 60 days) / 40 = 0.9 TB

S3 storage cost is just $20 for ~1TB of compressed logs.

Explore Secondary Storage today!

Secondary Storage features are available to all SaaS and Self Hosted Turbo customers. Secondary Storage is the easiest and simplest way to control your logs storage costs and stay compliant to long term regulatory and security requirements. What’s more? This feature comes at no extra cost.

To try SnappyFlow, start your 14-day free trial today.

Kubernetes Monitoring Simplified

KCD Chennai — Wed, 19 Jul 2023 06:54:17 +0000

Introduction

Today, organizations are transitioning from monolithic architecture to microservice architecture. When we speak of microservice architecture, there is no way to ignore Kubernetes (K8’s). K8’s is the leading open-source Container Orchestration Platform, and it holds a prominent position for certain reasons, such as: Robust, Scalability, High Availability, Portability, Multi-Cloud Support, Self-Healing, Auto-Scaling, Declarative Configuration, Rollbacks, Service Discovery, Load Balancing, among other features.

We all know Kubernetes is a powerful tool, but the question here is, how do I get the most out of it? The answer is simple: by proactively monitoring your Kubernetes cluster.

Challenges in Monitoring Kubernetes Clusters

Monitoring K8’s clusters can be a complicated task. Here are few difficulties faced by SRE’s.

Complexity: Kubernetes operates in a multi-layer environment, requiring the collection and correlation of metrics from pods, nodes, containers, and applications to obtain an overall performance metric of the cluster.

Security: Monitoring tools collect sensitive data from the Kubernetes cluster, raising security concerns that need to be addressed to protect the cluster data.

Data Flow: As the Kubernetes cluster grows, whether it's on the cloud or on-premises, tracing the data flow between endpoints becomes increasingly difficult.

Ephemerality: Kubernetes scales up and down based on demand. Pods created during scale-up disappear when no longer required. To avoid data loss, monitoring tools must collect metrics from various resources such as deployments, daemon sets, and jobs.

Benefits of Monitoring Kubernetes Clusters

Despite the challenges, monitoring K8’s environment can lead to significant benefits and improvements:

Enhanced Visibility: Monitoring Kubernetes clusters helps you gain enhanced visibility about overall health of your system and its components.

Proactive Issue Detection: Monitoring Kubernetes clusters enables you to proactively detect issues such as application failures, abnormal behaviours, and performance degradation. With the help of this you can prevent potential downtime and service disruptions.

Resource Utilization: By tracking the resource usage of your containers, pods, and nodes, you can fine-tune resource allocation, enhance efficiency, reduce costs, and maximize the utilization of the infrastructure.

Performance Optimization: Monitoring Kubernetes enables you to identify the slowness in the response times, inefficient resource usage and helps you to optimize scaling specific to components and optimize network settings to improve overall system performance.

Root Cause Analysis: Monitoring Kubernetes facilitates you to pinpoint the root cause, isolate problematic pods, or nodes, and analyse relevant logs and metrics.

Here comes the next question, how do I monitor my Kubernetes cluster? Monitoring Kubernetes is challenging task, but this is where monitoring tools like SnappyFlow come in handy.

Simplify Kubernetes Monitoring with SnappyFlow

SnappyFlow is a full stack application monitoring tool. By integrating your Kubernetes cluster with Snappyflow, it starts collecting the data from your cluster and enables efficient cluster monitoring. SnappyFlow monitors various aspects of the cluster which will help you to take an informed decision. Its alerting system notifies any deviation that happens in the cluster through your preferred communication channel.

What can you monitor with SnappyFlow?

Resource Utilization: SnappyFlow monitors CPU, memory, and disk usage of nodes, pods, and containers to identify resource bottlenecks. This helps to ensure efficient utilization of the resources and prevents overloading.

Pod Health: SnappyFlow tracks the status and health of individual pods, including their readiness and liveness probes. It monitors the pod failures, crashes, and restarts.

Cluster Capacity: SnappyFlow keeps an eye on cluster capacity to avoid resource exhaustion. It monitors the number of nodes, available resources, Daemon set, Deployment, Replica set, stateful set and the ability to schedule new pods. It also monitors how many critical and warning events are occurring in the cluster.

Network Performance: SnappyFlow monitors network traffic, latency, and throughput at node level.

Persistent Volumes: SnappyFlow monitors the status and capacity of persistent volumes (PVs) and their associated claims (PVCs). Ensure that storage resources are available and accessible as required. It also monitors Read and Write operations.

Service Discovery and Load Balancing: SnappyFlow monitors the health and availability of Kubernetes services and their endpoints. Track load balancing across pods to ensure even distribution of traffic.

Kubernetes API Server: SnappyFlow keeps an eye on the API server's performance, latency, and response times. Monitors for any errors, throttling, or potential bottlenecks in API communication.

Logging and Event Monitoring: SnappyFlow sets up centralized logging and monitoring to capture container logs, Kubernetes events, and system-level metrics. check for issues related to image pulling, container startup, or resource allocation. This enables quick troubleshooting and identification of issues.

Node Summary

Cluster Resource Utilization

Kubelet operation details

Conclusion

In summary, SnappyFlow offers a simplified and effective solution for monitoring Kubernetes clusters. By leveraging SnappyFlow, you can ensure the health and performance of your Kubernetes cluster while reducing the complexity and effort involved in monitoring.

GCP Cloud Function 2nd Gen CLI For A Compatible Ingress Cloud Shell In Variant Web App

Anshuman Mishra — Tue, 20 Jun 2023 07:52:52 +0000

1.
GCP Region/Zones Extraneous CLI For Downward Function With Parallel Kubernetes Pod:
gcloud enable googleapis artifactregistry.googleapis.com pubsub.googleapis.com - 1
export REGION=us-east4
gcloud config set compute/region $REGION
2.
Now,Let us populate Cloud Storage Javascript function With Ingress Audit Logs-

Python CLI:
`gcloud enable googleapis
artifactregistry.googleapis.com

Node.js 2 `

import os
color = os.environ.get('COLOR')- (Artifact Registry JSON Function With Ingress Python Function Only For One HTTP Port Node Instance)
def hello_world(request):
return f'

Hello World!

Kotlin/Java 11/Javascript CLI:

`gcloud enable googleapis
artifactregistry.googleapis.com
pubsub.googleapis.com

Node.js 3 (Cold Restarts Node From Public Subscription Javascript Topic To Kotlin CLI) `

Squeezed IntelliJ IDEA Ultimate IDE Coroutine From GCP
const qj = require('google-cloud/functions-framework');
qj.http('req/res',(req,res)=>{
res.status(200).send('HTTP function (2nd gen) has been called!');
});)
data class tp(val qw:Int,var qw2:Int)

fun main()
{
IntelliJ IDEA Kotlin Function 1 (Extraneous CLI For Multiple Warm Instance In Similar Methods For Cold Node Run Analysis For AI/ML,Web App)

val tq = qj.set() - Here We have to find out if Google Cloud Run function can be originated for similar Cold restarted nodes function(Point 1 Described Above)

}

Cloud Monitoring API For Enabled API And IAM Resources In GCP K8S Cloud Shell Region

Anshuman Mishra — Sat, 17 Jun 2023 06:30:47 +0000

Step 1:
Initializing GCP VM Instance SSH Node For Distributed YAML Function

Apache Server 1 - Metrics 1 API Cloud Monitoring

1st Cloud Backports API In Ingress Mode Analytics

Compatibility In GCP Cloud Storage Bucket And Its API/IAM For Retrieving Metrics:
Cloud Monitoring API
Workbench GUI 1:
curl -sS0 https://www.googleapis.com/GoogleCloudPlatform/(IAM/API 1).yaml

                 [Cloud Monitoring API](URL 2 Query)

                                          Workbench GUI 2:

curl -sS0 -l https://www.googleapis.com/GoogleCloudPlatform/(IAM/API2).yaml

-l indicates list of all CLI and GCP privileges that can be scaled for downward Pub/Sub topics allocated in a Cloud Shell
Step 2:
Query :
Select cpu.utilzation,api_privileges from GCP_Project_ID1,GCP_Project_ID2 where (Backport_Nodes MIN_BY Cloud Monitoring API) Group By GUI1,Apache Server 1
Group By GUI1,Apache Server 2(Depends upon frequency of GCP K8S Cloud Shell)

In the above query,We have to find out exact amount of CPU Utilization for simultaneous API that can be enabled for GUI 1 for both project_id

CI/CD Pipeline Dual Helm Github Repo With Similar Canary Deployment

Anshuman Mishra — Tue, 13 Jun 2023 06:06:30 +0000

Continuous Integration/Continuous Delivery VM Instance Pipeline:

$ gcloud config list project
[core]
GCP 2nd Gen Cloud Function Inflated With One Pub/Sub CLI Run For Squeezed Cloud Shell

gcloud pubsub(-Module 1) subscriptions create --topic myTopic mySubscription

        1.Inflated Pub/Sub index.js - 

              fun sleep(){
                      Pub/Sub Module 1.()

                                    - Module 2.() -Function 2(Here,Let us now identify if similar Cloud Function can be run in ingress way for another docker container enabled randomly to a subsequent Pub/Sub object) 

                       }

Java 11 Open JDK CLI: public class PipelineOptions implements Serializable
public String Module 2(){-Now let us redirect for one atomic Cloud Function to test its Dataflow API for another Similar Docker Container for a browser
void aq()
}
{
PipelineOptions xd = new PipelineOptions(new FileInputStream());
xd.Module 2() Function 2;
String xd = "";

--Subsequent Module Function's Cloud Storage Bucket

    gsutil ls gs://Storage_Bucket/().txt
                              1.CI/CD Pipeline API Analytics In Ingress Mode For Its Function In Storage Bucket 1

}

Conclusion:

Whenever We run GCP Kubernetes pod for one Storage Bucket,FileInputStream class are managed for its Java 11/Kotlin CLI for one ingress Dataflow Docker Container

Google Cloud Dataprep Initialization For One Data Schema and AI

Anshuman Mishra — Wed, 07 Jun 2023 06:51:08 +0000

us-east1
Adding zones for regional and multi-regional data in this lake.

Labels 1:
We have to find the exact Regular Expression for a data with its ingress VM where Lake data can be scaled for one API

Redirection Of Worker Node For One Named Zone:

gsutil create --zone name=""
type= "raw"
--region= "us-central1"

Now inserting data for raw zone needs exact Java/JSON API that can be run only at these region

open class sw:xd{
fun gy(){
println("h")
}
override fun toString(): String { - One atomic Kotlin's toString() function in one Dataplex Lake
return super.toString()
}
}
data class hu(val gq:Int)

fun main(){
val dw = sw().gy().equals("h")
val dw2 = sw().gy()
if(dw is String){

    val ki = ""?:"x"
    println(ki)
}-

2.Now let us consider a Kotlin CLI from IntelliJ IDEA IDE to GCP Dataprep with one data class

   --worker-node = 1
     data class (Dataprep Instance 1 for similar equals method)

{
"document":{
"type":"PLAIN_TEXT",
"content":"With approximately 8.2 million people residing in Boston, the capital city of Massachusetts is one of the largest in the United States."
},
"encodingType":"UTF8"
}- fun toString(){ val rq = ""?:"document"}
(IntelliJ IDEA Ultimate IDE JSON Function)

Google Cloud Dataprep Regex Pattern Schema To Entity/Sentiment Analysis CLI In A Dataplex:

(Labels 1 Described Above)-

gsutil create --zone name=""
type= "raw"
--region= "us-central1"

Now let us connect Dataplex raw zone with downward curl CLI for one enabled Cloud Shell described below:

curl -X -h "https://www.googleapis.com/Project_1/().json

 Kotlin Function CLI 1 -   googleapis.com/(Dataprep Instance1)

     interface qu{
      val gq = ()

}
data class ()(val aq:Int)

fun main(){
val qwp = arrayOf("","")

(Now We have to declare a GCP JSON Sentiment AI curl CLI here and interpret whether one Array object can be run for ingress Cloud Shell Dataplex Lake)
val qwp2 = ""?:data class(-Testing One GCP CLI AI object)
}

     Java/JSON CLI 1 -   googleapis.com/(Dataprep Instance2)
              import java.util.*;
             public class (){
               static public void main(String[] arg){
                ArrayList zs = new ArrayList();
                zs.add(Dataprep Instance2);-Here we have to find whether public ArrayList object can be injected with downward CLI for a Cloud Shell Lake for a browser region
                            }

AWS Project using SHELL SCRIPTING for DevOps

Poonam Pawar — Wed, 31 May 2023 10:00:31 +0000

Introduction

In the real-world DevOps scenario, The AWS Resource Tracker script is widely used to provide an overview of the AWS resources being utilised within an environment.

It aims to help organisations monitor and manage their AWS resources effectively. The script utilises the AWS Command Line Interface (CLI) to fetch information about different AWS services, such as S3 buckets, EC2 instances, Lambda functions, and IAM users.

What does this project do?

By running the AWS Resource Tracker script, users can quickly obtain a list of S3 buckets, EC2 instances, Lambda functions, and IAM users associated with their AWS account.

This information can be valuable for various purposes, including auditing, inventory management, resource optimisation, and security assessment.

Build the project

Create EC2 Instance

Step 1. Go to your AWS account and log in, then search for EC2 Instances in the search bar. Or you can click on the services button that is on the top left corner of your dashboard, from there also you can search for the same.

Then click on the Launch Instance button.

Step 2. Give it a name of your choice, ubuntu as a machine image, select your key-pair or create one if not have any. Leave the instance type t2.micro ie free tier as the same and click again on the Launch Instance button.

Now you can see your instance up and running like this.

Step 3. Now click on the instance id which will give you detailed information about the running instance, there copy the public IP address.

Run the Instance

Step 4. Now open up your terminal and run the below command.

ssh -i /Users/poonampawar/Downloads/my-key-pair.pem ubuntu@ip_add

We have to go inside the directory where you have downloaded your key-pair and in my case, it is in /Downloads folder.

Check yours and give a path accordingly. And don't forget to replace ip_add with your copied one. This will take you to the virtual machine which we have created in AWS.

Create the Script

Step 5. Now create a shell script file named aws_resource_tracker.sh and copy and paste the below script.



#########################
# Author: Your Name
# Date: 28/05/23
# Version: v1
#
# This script will report the AWS resource usage
########################

set -x

# AWS S3
# AWS EC2
# AWS Lambda
# AWS IAM Users

# list s3 buckets
echo "Print list of s3 buckets"
aws s3 ls

# list EC2 Instances
echo "Print list of ec2 instances"
aws ec2 describe-instances | jq '.Reservations[].Instances[].InstanceId'

# list lambda
echo "Print list of lambda functions"
aws lambda list-functions

# list IAM Users
echo "Print list of iam users"
aws iam list-users

It is a good convention to always provide your details so that it will make it easier for other developers to contribute if they want to ie, metadata.
The command set -x is given here in order to debug the script, this will print the command which we are running and then prints the output.
The commands aws s3 ls, aws lambda list-functions and aws iam list-users print the information of the given statement.

The command

aws ec2 describe instances | jq '.Reservations[].Instances[].InstanceId' will give you all the Instance IDs present in your aws in JSON format.

Test the script

Step 6. Run the below command to see the output.

./aws_resource_tracker.sh

The output will look like this.

Apply CronJob

To use cron jobs with your script, you can schedule it to run at specific intervals using the cron syntax. Here's an example of how you can modify your script to use cron jobs:

Open a terminal and run the following command to edit the
crontab file:
crontab -e
If prompted, choose your preferred text editor.

Add a new line to the crontab file to schedule your script. For example, to run the script every day at 9 AM, you can add the following line: 0 9 * * * /path/to/your/script.sh

Modify the path /path/to/your/script.sh to the actual
path where your script is located.

Save the crontab file and exit the text editor.
The above cron expression (0 9 * * *) represents the schedule: minute (0), hour (9), any day of the month, any month, and any day of the week. You can customize the schedule based on your requirements using the cron syntax.
By adding this line to the crontab file, your script will be executed automatically according to the defined schedule. The output of the script will be sent to your email address by default, or you can redirect the output to a file if needed.
Make sure that the script is executable (chmod +x /path/to/your/script.sh) and that the necessary environment variables and AWS CLI configurations are set up correctly for the script to run successfully within the cron environment.

Use Cases

Monitoring and auditing: By running this script periodically using cron jobs, you can monitor and audit your AWS resources. It provides insights into the status and details of different resources, such as S3 buckets, EC2 instances, Lambda functions, and IAM users.
Resource inventory: The script helps in maintaining an up-to-date inventory of your AWS resources. It lists the S3 buckets, EC2 instances, Lambda functions, and IAM users, allowing you to have a clear understanding of what resources exist in your environment.
Troubleshooting: In case of any issues or incidents, this script can be used to quickly gather information about the relevant AWS resources. For example, if there is an issue with an EC2 instance, you can run the script to get the instance ID and other details for further investigation.
Automation and reporting: The script can be integrated into an automated pipeline or workflow to generate regular reports about AWS resource usage. This information can be valuable for tracking costs, resource utilization, and compliance requirements.
Scalability and efficiency: In larger environments with numerous AWS resources, manually retrieving information about each resource can be time-consuming and error-prone. By using this script, you can automate the process and retrieve resource details in a consistent and efficient manner.

Overall, this script simplifies the process of gathering information about AWS resources, enhances visibility into your infrastructure, and supports effective management and monitoring of your DevOps environment.

Github link: https://github.com/Poonam1607/shell-scripting-projects

Resource: For better understanding and visual learning you can check out this tutorial - https://youtu.be/gx5E47R9fGk

This project is purely based on my learnings. It may occur error while performing in your setup. If you find any issue with it, feel free to reach out to me.

Thank you🖤!

Kubernetes Cluster Maintenance

Poonam Pawar — Tue, 30 May 2023 10:16:13 +0000

Introduction✍️

Till now we have done a lot of things!!🥹

Recap👇

Kubernetes Installation & Configurations

Kubernetes Networking, Workloads, Services

Kubernetes Storage & Security

kudos to you!👏🫡 This is literally a lot...!😮‍💨

By doing all these workloads your cluster is tiered now🤕. You have to give the energy back and make it faster. It is very important to make your cluster healthy😄 and fine.

So it's high time to understand the Kubernetes cluster maintenance stuff now.

In our today's learning, we will be covering cluster upgradation, backing up and restoring the data and scaling our Kubernetes cluster. So, let's get started!🚀

Cluster Upgradation♿

Let's say you are running your application in the Kubernetes cluster having master node and worker nodes. Pods and replicas are up and running.
Now you want to upgrade your nodes. As everyone wants to keep updated themselves and so do the nodes.
When a node is in upgradation mode, it generally goes down and is no longer in use. So you cannot keep your master and worker node together in the upgrade state.
So firstly, you will upgrade the master node. While it's upgrading, your worker node cannot deploy new pods or do any modifications. The Pods that are running already, only they will be available for the users to access.
Though the users are not going to be impacted as they still have the application up and running.
When the master node is done with the upgradation and again up and running, now we can upgrade our worker nodes. But in this also, we cannot make worker nodes goes down altogether as this may impact the users who are using the applications.
If we have three Worker nodes in our cluster, they will go one after the other in the upgrade state. When node01 goes down, the pods and replicas running in that node will shift to the other working nodes for a while ie in node02 and node03.
Then node02 will go down after node01 is upgraded and available again for the users. The pod distribution of node02 will go to node01 and node03.
And the same procedure will follow up to upgrade node03. This is how we upgrade our cluster in Kubernetes.
There is another way to upgrade the cluster, you can deploy a worker node with the updated version into your cluster and shift the workloads of the older one to the new ones then delete the older node. This is how you can achieve the upgradation.

Now let's do this practically. First, the master node:

kubeadm which is a tool for managing clusters has an upgrade command that helps in upgrading the clusters. Run:

kubeadm upgrade plan

Run the above command to see the detailed information on the upgrade plan and gives you the information of the upgrade plan if your system is needed.

Then run the drain command to make it un-schedulable:

Now install all the packages to use kubelet as it is a must in running controlplane node:

Now, Run the below command to upgrade the version:

apt-get upgrade -y kubeadm=1.12.0-00

Now to upgrade the cluster, run:

kubeadm upgrade apply v1.12.0

It will pull the necessary images and upgrade the cluster components.

Now run the below command to see the changes

systemctl restart kubelet

Now it's time to upgrade the worker node one at a time. Follow these commands:

# First move all the workloads of node-1 to the others

$ kubectl drain node-1
# this terminate all the pods from a node & reschedule them on others

$ apt-get upgrade -y kubeadm=1.12.0-00
$ apt-get upgrade -y kubelet=1.12.0-00

$ kubeadm upgrade node config --kubelet-version v1.12.0
# upgrade the node config for the new kubelet version

$ systemctl restart kubelet

# as we marked the node un-schedulable above, wee need to make schedule again
$ kubectl uncordon node-1

kubectl command will not work on the worker node, it will only work on the master node that's why after applying all the commands come back on the controlplane and make the node available again for scheduling.

Backup & Restore Methods🛗

We have till now deployed many numbers of applications in the Kubernetes cluster using pods, deployments and services.
So there are many files that are important to be backed up. Like the ETCD cluster where all the information about clusters is stored.
Persistent volumes storage is where we store the pod's data as we learned above.
You can store all these files in a source code repository like GitHub which is a good practice. In this even if you lost your whole cluster you still can deploy it again if you're using GitHub.
A better approach to back up your file is to query the kube-api server using the kubectl or by accessing the API server directly and saving all resource configurations for all objects created on the cluster as a copy.
You can also choose to back up the ETCD server itself instead of the files.
Like the screenshots on your phone, you take snapshots here of the database by using the etdctl utilities snapshot save command.

ETCDCTL_API=3 etcdctl \ snapshot save <name>

Now, if you want to restore the snapshot. First, you have to stop the server as the restore process requires the restart ETCD cluster and kube-api server

service kube-apiserver stop

Then run the restore command:

ETCDCTL_API=3 etcdctl \ snapshot restore <name> \ --data-dir <path>

Now restart the services which we stopped earlier

$systemctl daemon-reload
$service etcd restart
$service kube-apiserver start

Scaling Clusters📶

We have done the scaling of pods in the Kubernetes cluster very well. Now what if you want to scale your cluster? Let's see how it can be done.

According to the capacity worker nodes adjust themselves by adding or removing from the cluster.

Kubernetes provides several tools and methods for scaling a cluster, like:

Manual Scaling🫥
Horizontal Pod Autoscaler (HPA)▶️
Cluster Autoscaler↗️
Vertical Pod Autoscaler (VPA)⏫

Let's have a look at all one by one

Manual Scaling - As the name suggests, we have to scale it manually using the kubectl command. Or if you're using any cloud provider, increase or decrease the number of worker nodes manually.

Horizontal Pod Autoscaler (HPA) - It automatically scales the number of replicas of a deployment or a replica set based on the observed CPU utilisation or other custom metrics.

When defining the definition file, you must ensure the usage of memory and cpu

To use utilisation-based resource scaling, like this:

 type: Resource
 resource:
   name: cpu
   target:
     type: Utilization
     averageUtilization: 60

This is also known as "scaling out". It involves adding more replicas of a pod to a deployment or replica set to handle the increased load.

Cluster Autoscaler - Based on the pending pods and the available resources in the cluster, it automatically scales the number of worker nodes in a cluster.

Read more about this scaler in detail here!

Vertical Pod Autoscaler (VPA) - It automatically adjusts the resource requests and limits of the containers in a pod based on the observed resource usage.

It is also known as "scaling up," which involves increasing the CPU, memory, or other resources allocated to a single pod.

Thank you!🖤

Simply Deploying Kubernetes Workloads

Poonam Pawar — Mon, 29 May 2023 06:00:29 +0000

Introduction✍️

Before moving forward directly to our main topics let's recall the sub-topics which is crucial for the next ones. So that you can grasp the context in a much more clear way.

Every other Relationship👀

First, let's talk about every relationship which we have to keep in mind forever from now onward.

POD -> CONTAINER -> NODE -> CLUSTER

Are you thinking of the same as what I am thinking?

Dabbe pe dabba, uske upper phir se ek dabba...🤪

No?? Ok ok! Forgive me:)

(translation: don't mind it, please. Thank you!)

So basically you got the idea of how pods are encapsulated into the containers which are placed inside the node and the group of nodes becomes a cluster.

And we have already covered their workings in the previous articles.

Pre-requisites👉

So a must-have pre-requisite topic is ReplicaSets.

Now be serious guys and let's start the conversation on replicaset aka rs

ReplicaSets🗂️

Continuing the imagination from the previous blog of your application deployment...

You have your application running into a pod. Now suddenly your application traffic grows and you didn't prepare your app for this huge number and due to this it crashes.

Or imagine another scenario where you have to update your app version from 1.0 to 2.0 ie v1 to v2 and in doing so your app stops running and the users fail to access the application.

In case of application failure, you need another instance of your application that saves you from crashes and running at the same time. So that the users cannot lose access to the application.

This is where the replication controller (now as replicaset the upgradation version) comes in as a savior. ReplicaSets always takes care of running multiple instances of a single pod running in the k8s cluster.

It helps us to automatically bring up the new pod when the existing ones fail to run.

You can set it to either one or hundreds, it's totally up to your choice.

It also helps us to balance the load in our k8s clusters. It maintains the load balance when the demand increases by creating instances of the pod in other clusters too.

So, it helps us to scale our application when the demand increases.

A simple Replica Yaml file:

---
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      tier: nginx
  template:
    metadata:
      labels:
        tier: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

Then run:

kubectl create -f /root/replicaset-demo.yaml

To scale up or down your replicas, you can use kubectl scale command.

run:

kubectl scale rs replicaset-demo --replicas=5

To check the replicasets use get command:

kubectl get rs

This will show you all the previous and newly created replicas by you in the system.

This is how you can create replicas of your pods.

Deployments🏗️

This comes to the highest in the hierarchy level of deploying our applications to production.

When you have many instances running into the k8s cluster and want to update the version of your application then the rolling updates do their job one after the other instead of making it down at the same time and then up altogether for obvious reasons.

These rolling updates and rollback performance is done by the k8s deployment.

As we know that every pod deploys single instances of our application and each container is encapsulated in the pod and then such pods are deployed using replica sets.

Then comes Deployment with all the capabilities of doing upgradation of the whole set of environment production.

A simple deploymentyaml file deployment-definition-httpd.yaml:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd-frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      name: httpd-frontend
  template:
    metadata:
      labels:
        name: httpd-frontend
    spec:
      containers:
      - name: httpd-frontend
        image: httpd:2.4-alpine

Then run

kubectl create -f deployment-definition-httpd.yaml

To check the deployments you have created use get command, deployment aka deploy :

kubectl get deploy

You can also check for the specific one by giving its name:

kubectl get deploy httpd-frontend

To get more detailed information regarding the deployment, run the describe command:

kubectl describe deploy httpd-frontend

To check all the workloads you have created till now, use get all commands:

kubectl get all

This is how you can deploy your pods.

StatefulSets🏗️📑

Some topics will repeat themselves but for the sake of connecting them to the next one, it is necessary to do so. So bear with me.
The use of Deployment is to deploy all the pods together to make sure every pod is up and running, all these things we have seen above.
But what if you have many servers in the form of pods that you want it to run in order? For this, deployment will not help you because there is no order specified in it for running pods in the k8s cluster.
For that, you need StatefulSet. It ensures to run the pods in the sequential order which you want to run. First, the pod is deployed and it must be in a running state then only the second one will be deployed.
Stateful set is similar to deployment sets, they create pods based on the templates.
They can scale up and scale down as per the requirements. And can perform rolling updates and rollbacks.
Like, you want to deploy the master-node first then the worker-node-1 up completely then starts running and after that worker-node-2 will be up and run itself into the k8s cluster. StatefulSet can help you to achieve this.
As in the deployment sets, when a pod goes down and a new pod comes up, it is with a different pod name and different IPs come in.
But in StatefulSets when a pod goes down and a new pod comes up, it will be the same name that you have specifically defined for that pod.
So the StateulSets maintain an identity for each of its pods that helps to maintain the order of the deployment of your pods.
If you want to use StatefulSets just for the sake of identity purposes for the pods and not for the sequential deploying order then you can manually remove the commands of the order maintenance, just you have to make some changes in the YAML file.
Though It is not necessary for you to use this StatefulSet. As it totally depends on your need for the application. If you have servers that require an order to run or you need a stable naming convention for your pods. Then this is the right choice to use.
You can create a StatefulSet yaml file just like the deployment file with some changes like the main one is kind as StatefulSet. Take a look:

---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
  labels:
        app: msql
spec:
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql
  replicas: 3
  selector:
      matchLabels:
          app: mysql
  serviceName: mysql-h

than run:

kubectl create -f statefulset-definition.yml

To scale up or down use the scale command with the numbers you wanted to scale:

kubectl scale statefulset mysql --replicas=5

This is how you can work with StatefulSets.

DaemonSets🤖

Till now, we have deployed the replicasets as per the demand so the required number of pods is always up and running.

Daemon sets are like replica sets. It helps you to deploy multiple instances of the pod.

So what's the difference?

It runs one copy of your pod on each node of your cluster.

Whenever you add a new node, it makes sure that a replica of the pod is automatically added to that node. And removed automatically when the node is removed.

The main difference is, the daemon sets make sure that one copy of the pod is always present in all the nodes in the k8s cluster. On the other hand replica set runs a specified number of replicas of the pod which you defined in the YAML file.

It is also used to deploy the monitoring agent in the form of a pod.

Creating a daemon file is much similar to the replica file which we have already created above. You just have to make some changes and you are done.

The main difference is of course the kind ie ReplicaSet to DaemonSet

Take a look fluentd.yaml is the name of the file with the content below:

---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    app: elasticsearch
  name: elasticsearch
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: elasticsearch
  template:
    metadata:
      labels:
        app: elasticsearch
    spec:
      containers:
      - image: registry.k8s.io/fluentd-elasticsearch:1.20
        name: fluentd-elasticsearch

Then run the following command:

kubectl apply -f fluentd.yaml

To get the daemonstate with all the namespace which you have created, run:

kubectl get daemonsets --all-namespaces

This is how you can create DemonSets

JOBS🧑‍💻

As we all know, Kubernetes ensures that our application is always up and running no matter what.

Let's say we perform work in our application and when it successfully completed it shows the successful message and then again comes in a running state because that's the nature of k8s.

Jobs in k8s does the work in your application and when it becomes successful it shows the completed message and then stops the work as it is no longer in use.

But why do we need JOBS?

Let's assume you are using your camera and clicked some pictures. So this enabling of camera work is going on in your application, k8s is running your app in the pod and after use, you disabled your camera. But k8s again starts running it as it always looks up for the application up and running. And you are unaware of this pod running.

Then isn't it a dangerous task?

That's why we need JOBS so that in a specific work when the task is completed it does not go into a running state again.

So a task you may not want to run continuously, then using a Job would be appropriate. Once the task is complete, the Job can be terminated, and the pod will not start again unless a new Job is created.

It is done so because a spec member ie restartPolicy is set as always by default.

So in the creation of the JOBS yaml file, we set it to never

Run the command to create a job definition file.

kubectl create job throw-dice-job --image=kodekloud/throw-dice --dry-run=client -o yaml > throw-dice-job.yaml

Use the following YAML file to create the job:

apiVersion: batch/v1
kind: Job
metadata:
  name: throw-dice-job
spec:
  backoffLimit: 15 # This is so the job does not quit before it succeeds.
  template:
    spec:
      containers:
      - name: throw-dice
        image: kodekloud/throw-dice
      restartPolicy: Never

In the above file, we have created a JOB to throw the dice until it gets six and the chances offered is 15 times to play.

kubectl apply -f throw-dice-job.yaml

This is how you can create your own job file.

CronJob🥸

A CronJob is a JOB that will perform the task on a given time period.

You can schedule your job to do a task at a specific time you want.

It supports complex scheduling, with the ability to specify the minute, hour, day of the month, month, and day of the week.

It can be used to create one-off Jobs or Jobs that run multiple times.

It can be used to run parallel processing tasks by specifying the number of pods to be created.

Example,

Updating the phone at midnight to avoid interruptions while using the phone.🤳
Email scheduling, you schedule an email using cronjob to perform this task. periodically.🧑‍💻

Let us now schedule a job to run at 21:30 hours every day.

Create a CronJob for this.

Use the following YAML file:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: throw-dice-cron-job
spec:
  schedule: "30 21 * * *"
  jobTemplate:
    spec:
      completions: 3
      parallelism: 3
      backoffLimit: 25 # This is so the job does not quit before it succeeds.
      template:
        spec:
          containers:
          - name: throw-dice
            image: kodekloud/throw-dice
          restartPolicy: Never

This is how you can use the CronJob file.

Every example I have given above is just for the sake of explanation. Don't take that seriously.

Now we have deployed every workload of the Kubernetes cluster. It takes practice to make hands-free in creating replicas, deployments, jobs etc. So do the practice.

Thank you!🖤

Vertex AI And GCP Cloud Dataprep VM Instantiation For One JSON Function In A Cloud Shell

Anshuman Mishra — Mon, 29 May 2023 04:59:38 +0000

GCP JSON CLI For One Virtual Machine Instance:

--worker-nodes n1-standard-1
n2-standard-2

                 gsutil cp gs://(

VM Node 1 In Cloud Shell Browser)
)
--worker-node:1
n1-standard-1(JavaScript Atomic Function Scalability):
```
                    index.js: const functions = require('@google-cloud/functions-framework');
```
functions.cloudEvent('eventStorage', (cloudevent) => {
console.log('A new event in your Cloud Storage bucket has been logged!');
console.log(cloudevent);
});
-Now We have to detect the exact function for Cloud Storage Bucket CLI for one cloud event where its downward AI/ML API can be run in ingress Cloud Shell

Kubernetes Networking

Poonam Pawar — Sat, 27 May 2023 09:18:32 +0000

Introduction✍️

Networking in k8s is such a crucial topic to understand and a must for working in k8s. Here we will discuss networking, particularly in the work use of k8s directly. So before you come to this topic you must have knowledge of basic computer networking.

Switching
Routing
Gateways
Bridges

PODS📦

Before jumping right into the Kubernetes networking stuff. First, let's recall the Pods concept because we will be using Pods in every sentence further.
Whatever we are doing, the main goal is to deploy our application in the form of containers on a worker node in the cluster which must be up and running.
As Kubernetes does not deploy the containers directly on the nodes.
The containers are encapsulated into an object known as Pods
The Pod is a single instance of an application.
A Pod is the smallest object that you can create in Kubernetes.
A simple yaml pod file:


      apiVersion: v1
      kind: Pod
      metadata:
        name: demo-pod
      spec:
        containers:
        - name: demo-container
          image: nginx
          ports:
          - containerPort: 80

Then run the kubectl apply command once you have created the YAML file to deploy it in the Kubernetes cluster with the necessary file name you have given.

kubectl apply -f demo-pod.yaml

This is how you can start creating PODs.

Network Policies📋

In Kubernetes, every routing network traffic instruction is set by the network policies.
A set of tools that defines the communication between the pods in a cluster.
It is a powerful tool used for the security of network traffic in k8s clusters.
Allowance of traffics from one specific pod to another one.
Restricting traffic to a specific set of ports and protocols.
Implementation is done by Network APIs.
It can be applied to namespaces or individual pods.
A simple network policy yaml file:

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: demo-network-policy
  spec:
    podSelector:
      matchLabels:
        app: my-app
    policyTypes:
    - Ingress
    ingress:
    - from:
      - podSelector:
          matchLabels:
            app: allowed-app
      ports:
      - protocol: TCP
        port: 80

For the deployment of the Network Policy YAML file, use the kubectl apply command:

kubectl apply -f demo-network-policy.yaml

This is how you can define your own network policies.

Services🪖

Let's say, you deployed a pod having a web application running on it and you want to access your application outside the pod. Then how to access the application as an external user?

The k8s cluster setup in your local machine has an IP address similar to your system IP but the pod has a different IP address which is inside the node.

As the pod and your system share different addresses, there is no way to access the application directly into the system.

So we need something in-between to fill the gap and gives us access to web application directly from our systems.

Getting started with Kubernetes Services - Spectro Cloud

This is where Kubernetes Services comes into the picture.

k8s services activate the communication between several components inside-out the application.
It helps us to connect the application together with other applications and users.
It is an object just like PODs, Replicas and Deployments.
It listens to a port on the node and forwards the requests to the port where the application is running inside the pod.

A simple service yaml file:

apiVersion: v1
kind: Service
metadata:
  name: demo-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Services Types📑:

NodePort Service
ClusterIP Service
LoadBalancer Service

1) NodePort Service - It makes an internal POD accessible to the Port on the Node.

the port number inside the pod is the target port
the port number in the service area is the 2nd Port
and the port on the node is NodePort where we're going to access the web server externally.
the valid range of NodePort (by default): 3000 to 32767
labels & selectors are necessary to describe in the spec section in case of multiple pods in a node or multiple nodes in a cluster.

2) ClusterIP Service - It creates a virtual IP inside the cluster to enable communication between different services.

a service created of a tier of your application like backend or frontend which helps to group all the pods of a tier and provide a single interface for other pods to access this service.

3) LoadBalancer Service - It exposes the service on a publicly accessible IP address in a supported cloud provider.

A demo NodePort yaml file:

apiVersion: v1
kind: Service
metadata:
  name: my-demo-service
spec:
  type: NodePort
  selector:
    run: nginx
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30007

now run,

kubectl create -f myservice.yaml

This is how you can create your service of NodePort type. By changing the spec type to ClusterIP or LoadBalancer, whatever you wish to work with just change it with the name and port according to it.

CNI (Computer Network Interface)🌐

CNI is a set of standards that defines how to configure networking challenges in a container runtime environment like Docker and Kubernetes.
It is a simple plugin-based architecture.
It defines how the plugin should be developed.
Plugins are responsible for configuring the network interface.
CNI comes with a set of supported plugins already. Like bridge, VLAN, IPVLAN, MACVLAN.
Docker does not implement CNI. It has its own set of standards known as CNM ie, Container Network Model.
We cannot run a docker container to specify the network plugin to use CNI.
But you can do it manually by creating a docker container without any network configuration

docker run --network=none nginx
then invoke the bridge plugin by yourself.

CNI in k8s🕸️

Kubernetes is responsible for creating container network namespaces
Attaching those namespaces to the right network
You can see the network plugins set to CNI by running the below command

ps -aux | grep kubelet

The CNI plugin is configured in the kubelet service on each node in the cluster
The CNI bin directory has all the supported CNI plugins as executables.

ls /opt/cni/bin

k8s supports various CNI plugins like Calico, Weave Net, Flannel, DHCP and many more.
You can identify which plugin is currently used with the help of this command

ls /etc/cni/net.d

kubelet finds out which plugin will be used.

DNS in k8s📡

Kubernetes deploys a built-in DNS server by default when you set up a cluster.
Let's say we have three nodes k8s cluster having pods and services deployed in it having node name and IP address assigned to each one.
All pods and services can connect to each other using their IPs and to make the web app available to external users we have services defined on them.
Every new entry of a pod goes into the DNS server record by

cat >> /etc/resolv.conf

The k8s DNS keeps the record of the created services and maps the service name to the IP address. So anyone can reach by the service name itself.
DNS implemented by Kubernetes was known as kube-dns and later versions CoreDNS.
The CoreDNS server is deployed as a POD in the kube-system namespace in the k8s cluster.
To look for DNS Pods, run the command

kubectl get pods -n kube-system

Ingress🔵

Let's say you have an application deployed in the k8s cluster with a database pod having required services for external accessing with the NodePort in it. The replicas are going up and down as per the demand of the application.
You configured the DNS server so that anyone can access the web app by typing their name instead of IP address every time
like, http://my-app.com:port instead of http://<node-ip>:port and if you do not want others to type port number also then you served a proxy-server layer between your cluster and DNS server. so that anyone can access it by just
http://my-app.com
Now, you want some new features to be added to your application. You developed the code and deployed the webapp again for the new features of pods and services into the cluster. Again setting up the proxy server in-between to access the webapp in just a single domain.
Maintaining all these outside the cluster is a tedious task to do when your application scales. Every time a new feature adds on, you have to do all the layerings again and again.
This is where Ingress comes in. Ingress helps users to access your application with a single URL.
Ingress is just another k8s definition file inside the cluster
You have to expose it one time to make it accessible outside the cluster either with NodePort or the cloud provider like GCP which uses the LoadBalancer service.

Ingress Controller🔹

In the case of using ingress in a k8s cluster, an ingress controller must be deployed and configured.
Mostly used ingress controllers are Nginx, Traefik, and Istio.
Deploy the application on the k8s cluster and configure them to route traffic to other services.
The configuration involves defining URL Routes, Configuring SSL certificates etc. This set of rules to configure ingress is called an Ingress Resource.
Once the controller is running, resources can be created next and configured to route traffic to different services in the cluster.
It is created using definition files like the previous ones we created for Pods, Services and Deployments.
Ingress Controller is not built-in in them by default. You have to create it manually.
A simple ingress yaml file for the sake of explanation:

      apiVersion: networking.k8s.io/v1
      kind: Ingress
      metadata:
        name: minimal-ingress
        annotations
          nginx.ingress.kubernetes.io/rewrite-target: /
      spec:
        ingressClassName: nginx-example
        rules:
        - http:
            paths:
            - path: /testpath
              pathType: Prefix
              backend:
                service:
                  name: test
                  port:
                    number: 80

Create a single ingress called 'simple' that directs requests to foo.com/bar to svc # svc1:8080 with a tls secret "my-cert"

      kubectl create ingress simple --rule="foo.com/bar=svc1:8080,tls=my-cert"

This is how you can start working with Ingress in Kubernetes.

Thankyou!🖤