heydevops_telugu

Hi Andarki,

Meelo chala mandi jobs kosam try chestunaru so e channel lo manam devops/sre inka clouid technologies chala easy way lo nerchukuntam.

Meeku em doubts unna sare comment chayndi inka mana telugu devops community join avvandi.

Thanks


heydevops_telugu

25 Kubernetes Production Issues Every DevOps Engineer Should Know openinapp.link/24l9x

Most Kubernetes tutorials teach you how to deploy applications.



Production teaches you how to debug them.



Here are 25 issues that almost every DevOps Engineer encounters in real-world



Kubernetes environments:



CrashLoopBackOff

ImagePullBackOff

OOMKilled

Pending Pods

Node Not Ready

Readiness Probe Failed

Liveness Probe Failed

DNS Resolution Issues (CoreDNS)

Persistent Volume Claim (PVC) Pending

Persistent Volume Full

High CPU Utilization

High Memory Utilization

Service Not Reachable

Ingress Not Working

TLS/SSL Certificate Expired

Secrets Not Mounted Correctly

ConfigMap Changes Not Reflected

Deployment Rollout Stuck

NetworkPolicy Blocking Traffic

Horizontal Pod Autoscaler (HPA) Not Scaling

etcd Performance Bottlenecks

Kubernetes API Server Latency

Worker Node Disk Pressure / Disk Full

Failed Rolling Updates

Namespace Stuck in Terminating



Knowing the issue is only half the battle.



A skilled Kubernetes engineer should also know:



• How to identify the root cause

• Which kubectl commands to use

• What logs and events to inspect

• How to resolve the issue quickly

• How to prevent it from happening again



Over the next few weeks, I'll be creating a series where I break down each production issue with:



Symptoms

Root Cause

Debugging Commands

Resolution Steps

Best Practices



If you're preparing for DevOps interviews or managing Kubernetes clusters in production, this series will be valuable.



Which Kubernetes production issue has consumed the most hours of your life?



PS: If you are preparing for Job search then openinapp.link/24l9x

Make sure you save this post by resharing so that it stays on your linkedin wall



#Kubernetes #DevOps

5 days ago | [YT] | 36

heydevops_telugu

80% of Linux work can be done with just 20 commands.
When I first started learning Linux, I thought I had to memorize hundreds of commands.



I was wrong.



Over time, I noticed the same commands kept appearing every single day.



grep

find

awk

sed

tail

top

ps

curl

chmod

df



These commands became muscle memory.



The lesson?



Don't try to learn everything.



Master the basics so well that solving problems becomes second nature.



I've attached a cheat sheet that every beginner should bookmark.



If you're learning Linux, save this post—you'll thank yourself later.



#Linux #Learning #DevOps #TechTips #Cloud

1 week ago | [YT] | 64

heydevops_telugu

Interviewer vs Candidate - Python Coding Challenge
Interviewer: How would you automate a Control-M job submission without opening the GUI?



Candidate: I'd use the Control-M Automation API with Python.



Interviewer: Interesting. Walk me through it.



Candidate:



Accept Control-M server, folder, job name, and order date as command-line arguments.



Build the JSON payload dynamically.



Authenticate using an API token.



Submit the job using a simple POST request.



Validate the response.



Extract the Run ID for tracking and monitoring.



Interviewer: Why is this better than manual ordering?



Candidate: Because automation saves time, reduces human error, integrates easily with CI/CD pipelines, and enables event-driven scheduling without ever logging into the Control-M UI.



Interviewer: Can this be extended?



Candidate: Absolutely.

Trigger jobs from Jenkins, GitHub Actions, or Azure DevOps.

Order multiple folders dynamically.

Monitor execution status.

Send Teams or Slack notifications.

Build complete end-to-end workload automation.



Interviewer: You're hired.



DevOps / SRE salaries revealed - yt.openinapp.co/ylhhs



Like and Repost this with your SRE friends

1 week ago | [YT] | 33

heydevops_telugu

Can You Remember These Networking Ports in Under 60 Seconds?
Here's the easiest way to remember the most common networking ports:



20-21 → FTP

20 bags + 21 boxes = File Transfer



22 → SSH

22 is your secure key to the server.



23 → Telnet

One step after SSH, but without security." (Avoid in production!)



25 → SMTP

25 delivers your emails." Think 25 = Send Mail



53 → DNS

53 translates names into IP addresses." (The Internet's phonebook.)



80 → HTTP

80 = Websites without security.



110 → POP3

110 pulls emails into your inbox.



443 → HTTPS

443 = Secure websites.Every time you see the lock icon, think 443.



3389 → RDP

3389 = Remote Desktop." Your computer, from anywhere



Quick Memory Trick:

FTP → 20-21

SSH → 22

Telnet → 23

SMTP → 25

DNS → 53

HTTP → 80

POP3 → 110

HTTPS → 443

RDP → 3389



Challenge:

Without looking back, can you name the service running on Port 53 and Port 443?



Drop your answers below



Subscribe to my telugu youtube channel - lnkd.in/g_EHQ38N



Subscribe to my english youtube channel - lnkd.in/g9x6K4Tk



Share & Save this post—you'll thank yourself before your next networking interview or certification exam.

2 weeks ago | [YT] | 36

heydevops_telugu

AWS has 200+ services. Do you really need to learn all of them?
When I first looked at AWS, I thought I had to memorize every single service.
S3, EC2, Lambda, ECS, IAM, Route 53, CloudWatch... the list just kept growing.

Then I realized something:
You don't learn AWS by learning all the services.
You learn AWS by understanding the building blocks.

Think of it like building a house

Storage → S3, EBS, EFS
Compute → EC2, Lambda, ECS
Networking → VPC, Route 53, API Gateway
Databases → DynamoDB, RDS, Aurora
Monitoring → CloudWatch, CloudTrail
Security → IAM, KMS, WAF, GuardDuty
DevOps → CodeCommit, CodeBuild, CodeDeploy, CodePipeline
AI & ML → SageMaker, Lex, Rekognition

Once you understand these categories, AWS suddenly becomes much easier.
You don't have to know everything.

Start with:

EC2
S3
IAM
VPC
RDS
CloudWatch

These six services alone will help you understand the foundation of cloud computing.

Remember:

Don't chase AWS services. Learn how they work together to solve real-world problems.

That's when cloud starts making sense.

Which AWS service was the most confusing when you started? 👇

Checkout my telugu youtube channel - lnkd.in/g_EHQ38N

Checkout my english youtube channel - lnkd.in/g9x6K4Tk

PS: Found this post helpful?? Do share with your community :)

2 weeks ago | [YT] | 38

heydevops_telugu

If I had to explain AWS in 1 minute

S3 → A giant online cupboard.
EC2 → A computer you rent.
Lambda → A robot that works only when called.
RDS → A database someone else manages.
IAM → Who gets the keys.
CloudWatch → Your system's security camera.
Route 53 → The internet's address book.
ECS/EKS → Managers for your containers.

Simple explanations make complex technologies easier to remember.

Which AWS service took you the longest to understand?

hashtag#AWS hashtag#CloudComputing hashtag#DevOps hashtag#Programming hashtag#TechCommunity hashtag#CloudLearning

2 weeks ago | [YT] | 39

heydevops_telugu

If software had a heart, Linux would be one of its strongest beats. ❤️
Most people see websites.

Engineers see servers.

Experienced engineers see everything happening underneath.



A single click on a website triggers:



Network communication

Kernel scheduling

Web server processing

Application execution

Database queries

Response generation



All within milliseconds.



Linux makes this possible.

That's why Linux powers:



Cloud platforms

Most web servers

Databases

Containers

CI/CD pipelines

Virtualization

AI infrastructure

Edge devices



The more I learn Linux, the more I realize:

Linux isn't just an operating system.

It's the foundation on which modern computing is built.

For freshers:

Don't just learn commands.

Learn why Linux works the way it does.



That knowledge compounds throughout your career.



#Linux #Learning #DevOps #Cloud #SoftwareEngineering #Backend #TechCareers

3 weeks ago | [YT] | 29

heydevops_telugu

The day I realized Kubernetes isn't as scary as its logo.





When I first heard the word Kubernetes, I thought it was something only DevOps engineers with 10+ years of experience could understand.



Then I opened a cheat sheet.



Instead of memorizing everything, I imagined a simple story.



Imagine you're managing a food delivery business.



Container = A chef preparing food.

Pod = The kitchen where one or more chefs work together.

Service = The restaurant's phone number customers always call, even if chefs change.

Deployment = The manager ensuring enough chefs are available during peak hours.

Secret = The safe where passwords and API keys are stored.

ConfigMap = The notice board with today's menu and settings.

Ingress = The main entrance guiding customers to the right restaurant.



Suddenly, Kubernetes stopped looking like a monster.



It became a system that simply answers three questions:



Where should my application run?

How can users reach it?

What happens if something breaks?



The biggest lesson I learned wasn't Kubernetes itself.



It was this:

Every complex technology becomes simple once you understand the story behind it.



As freshers, we often feel pressured to know everything.





You don't have to.



Start with one concept.

Understand why it exists.

Build one small project.

Repeat.



One day, you'll look back and realize the terms that once felt intimidating have become part of your daily vocabulary.



Learning isn't about memorizing commands.



It's about connecting concepts.



And that's where confidence begins. 🚀



Subscribe to my youtube channel for any Job help - yt.openinapp.co/pyjbh



PS: Reshare this post so that it stays on your linkedin wall



#Kubernetes #DevOps #CloudComputing #Freshers #LearningJourney

3 weeks ago | [YT] | 53

heydevops_telugu

Every Linux command you run follows an incredible journey.
Power On ⚡



Bootloader



Kernel



User Space



System Calls



CPU • Memory • Disk • Network



The Linux Kernel is the silent hero that manages:



Memory

Processes

File Systems

Device Drivers

Networking



Master this architecture, and Linux becomes much easier to understand.



Learning commands is good.

Understanding why they work is even better.



Happy Learning!



Subscribe to my youtube channel for any DevOps help - yt.openinapp.co/pyjbh



#Linux #DevOps #CloudComputing #Kubernetes #Programming #TechEducation #OpenSource #SysAdmin

3 weeks ago | [YT] | 24

heydevops_telugu

I am dealing with AWS first time. I am designing the architecture for our applications in organization.

I studied and designed one. I am sharing the picture so please look at it and suggest me if i missed anything in that (or) if anything to added or removed (or) if any mistakes in that.

Please suggest me how many ec2 servers need to launch for this scenario ?

This is what one of my student and I have suggested few of the changes

1) Use an Application Load Balancer (ALB) explicitly

In the diagram it says ELB. For a modern web application, use ALB in front of the web tier, especially for HTTP/HTTPS, path-based routing, and health checks.

2) Keep web tier and app tier in Auto Scaling Groups

That is correct in your diagram. Do not think in terms of fixed EC2 boxes. Think:
Web tier = ASG
App tier = ASG

3) Database should be Multi-AZ

Your DB placement looks fine, but for production I would strongly recommend:
RDS Multi-AZ
Private subnets only
Backups enabled
Read replica only if you really need read scaling

4) NAT Gateway per AZ

If this is production and highly available, place one NAT Gateway in each AZ. A single NAT Gateway is a single point of failure.

5) Some services in the diagram look unnecessary unless you truly need them
These may be valid, but only if your application actually uses them:

CloudFormation: good for provisioning, not part of runtime architecture
SES: only if your app sends email
SNS: only if you need notifications/alerts/integration
DynamoDB: only if you need NoSQL data
PowerShell: not usually shown as an architecture component unless it is part of ops automation
Cache: if needed, show it as ElastiCache (Redis/Memcached)

6) Security groups vs NACLs

Both are fine, but in most application architectures:
Security Groups do most of the real work
NACLs are optional and often kept simple

7) CloudFront + S3

This is good if you serve static content, images, JS/CSS, or downloads.
If the app is mostly internal or not internet-facing, CloudFront may not be required.

If you have read the post till here make sure you share with your community and watch my youtube channel for any job help lnkd.in/gBWK_zpK

4 weeks ago | [YT] | 28