Yury P.

Before You Ship to Production… Read This. Too many teams treat Kubernetes like it’s still running in staging. Then comes the late-night pager. Downtime. Blame games. After mentoring dozens of engineers and seeing real outages firsthand, I have documented the 10 Non-Negotiables for Running Kubernetes in Production, no fluff, just hard-earned lessons. From probes to autoscaling, from secrets to security, this is the checklist you never skip. Follow Bavithran M for more DevOps, Kubernetes, and cloud-native insights. 🔁Don't keep this to yourself, share it with your network and help someone improve their Kubernetes resilience! #kubernetes #devops #cloudnative #productionready #platformengineering #careerbytecode CareerByteCode #bavicnative #DevSecOps #Azure #AWS #GCP #Job #Interview #Career #Linkedin #Troubleshooting

284

47 comentarios

𝟯 𝗦𝘁𝗲𝗽𝘀 𝗧𝗼 𝗦𝗲𝘁𝘁𝗶𝗻𝗴 𝗨𝗽 𝗠𝘂𝗹𝘁𝗶-𝗖𝗹𝘂𝗱 𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺: Most Terraform repos 𝘤𝘰𝘭𝘭𝘢𝘱𝘴𝘦 the second you add more than one Cloud. Here’s the 3-part structure that keeps 𝐦𝐮𝐥𝐭𝐢-𝐜𝐥𝐨𝐮𝐝 Terraform clean and scalable 👇🏽 1️⃣ 𝐂𝐥𝐨𝐮𝐝-𝐬𝐩𝐞𝐜𝐢𝐟𝐢𝐜 𝐜𝐨𝐝𝐞 ▶ multi-cloud-terraform/ holds separate folders for 𝐀𝐖𝐒 and 𝐀𝐳𝐮𝐫𝐞. ▶ Each has its own 𝐦𝐚𝐢𝐧.𝐭𝐟, 𝐯𝐚𝐫𝐢𝐚𝐛𝐥𝐞𝐬.𝐭𝐟, and 𝐨𝐮𝐭𝐩𝐮𝐭𝐬.𝐭𝐟. ▶ This keeps the logic for each provider clear and isolated. 2️⃣ 𝐑𝐞𝐮𝐬𝐚𝐛𝐥𝐞 𝐦𝐨𝐝𝐮𝐥𝐞𝐬 ▶ Inside modules/, you define building blocks like: AWS storage Azure compute Shared networking ▶ Write once, use many times. No duplication. 3️⃣ 𝐄𝐧𝐯𝐢𝐫𝐨𝐧𝐦𝐞𝐧𝐭 𝐜𝐨𝐧𝐟𝐢𝐠𝐬 ▶ envs/ contains dev, test, and prod. ▶ Each environment has its own backend, variables, and provider files. ▶ Same codebase, different settings, isolated deployments. 𝐖𝐡𝐲 𝐢𝐭 𝐦𝐚𝐭𝐭𝐞𝐫𝐬: ✅ No duplication across clouds ✅ Teams scale without stepping on each other ✅ Environments stay clean and consistent 𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺 𝗶𝘀 𝗽𝗼𝘄𝗲𝗿𝗳𝘂𝗹, 𝗯𝘂𝘁 𝗼𝗻𝗹𝘆 𝗶𝗳 𝘆𝗼𝘂 𝗱𝗲𝘀𝗶𝗴𝗻 𝗳𝗼𝗿 𝗴𝗿𝗼𝘄𝘁𝗵. 𝗛𝗼𝘄 𝗵𝗮𝘃𝗲 𝘆𝗼𝘂 𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 𝗺𝘂𝗹𝘁𝗶-𝗰𝗹𝗼𝘂𝗱 𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺 𝗶𝗻 𝘆𝗼𝘂𝗿 𝗽𝗿𝗼𝗷𝗲𝗰𝘁𝘀?

231

9 comentarios

𝐊𝐮𝐛𝐞𝐫𝐧𝐞𝐭𝐞𝐬 𝐬𝐢𝐦𝐩𝐥𝐢𝐟𝐢𝐞𝐝: 𝐓𝐡𝐞 𝐛𝐫𝐚𝐢𝐧 𝐚𝐧𝐝 𝐦𝐮𝐬𝐜𝐥𝐞 𝐛𝐞𝐡𝐢𝐧𝐝 𝐦𝐨𝐝𝐞𝐫𝐧 𝐚𝐩𝐩𝐬 90% of companies running cloud-native applications today rely on Kubernetes. But very few actually understand how its internal architecture works. 𝐇𝐞𝐫𝐞 𝐢𝐬 𝐚 𝐡𝐢𝐠𝐡-𝐥𝐞𝐯𝐞𝐥 𝐛𝐫𝐞𝐚𝐤𝐝𝐨𝐰𝐧 𝐲𝐨𝐮 𝐜𝐚𝐧𝐧𝐨𝐭 𝐦𝐢𝐬𝐬: 𝟏. 𝐌𝐚𝐬𝐭𝐞𝐫 𝐂𝐨𝐦𝐩𝐨𝐧𝐞𝐧𝐭𝐬 (𝐓𝐡𝐞 𝐁𝐫𝐚𝐢𝐧) - API Server (REST API): The entry point for all requests. Developers talk to Kubernetes here. - etcd (Key-Value DB): Stores the cluster state which pod runs where, configs, secrets. Think of it as Kubernetes’ memory. - Scheduler: Decides which node gets which pod based on resources and rules. - Controller Manager: Keeps everything running as expected by watching and reconciling desired vs actual state. 𝟐. 𝐍𝐨𝐝𝐞 𝐂𝐨𝐦𝐩𝐨𝐧𝐞𝐧𝐭𝐬 (𝐓𝐡𝐞 𝐌𝐮𝐬𝐜𝐥𝐞) 𝐄𝐚𝐜𝐡 𝐧𝐨𝐝𝐞 𝐢𝐬 𝐚 𝐰𝐨𝐫𝐤𝐞𝐫 𝐦𝐚𝐜𝐡𝐢𝐧𝐞 𝐫𝐮𝐧𝐧𝐢𝐧𝐠 𝐭𝐡𝐞 𝐚𝐜𝐭𝐮𝐚𝐥 𝐜𝐨𝐧𝐭𝐚𝐢𝐧𝐞𝐫𝐬. 𝐈𝐧𝐬𝐢𝐝𝐞 𝐞𝐯𝐞𝐫𝐲 𝐧𝐨𝐝𝐞: - Kubelet: Talks to the master and makes sure containers are healthy and running. - Container Runtime (Docker, containerd, etc): Runs the containers themselves. - Networking: Handles pod-to-pod and pod-to-service communication. - OS + Hardware: The foundation that provides CPU, memory, and storage. 𝟑. 𝐇𝐨𝐰 𝐈𝐭 𝐀𝐥𝐥 𝐂𝐨𝐧𝐧𝐞𝐜𝐭𝐬 Users send commands → API Server validates → Scheduler places workloads → Nodes execute via Kubelet and Container Runtime → etcd keeps track of the truth. This master-worker model ensures apps scale automatically, recover from failures, and remain resilient. --- 𝐖𝐡𝐲 𝐢𝐭 𝐦𝐚𝐭𝐭𝐞𝐫𝐬 Kubernetes is not just a DevOps tool, it’s the operating system of the cloud. If you are in software, DevOps, or cloud engineering, mastering Kubernetes is no longer optional it’s foundational. Is your team running Kubernetes clusters in production today, or are you still experimenting in dev/test environments? ♻️ Repost this to help your network get started ➕ Follow Jaswindder Kummar for more #Kubernetes #DevOps #CloudComputing #Containers

383

18 comentarios

Grafana Loki Architecture 🚀 In this blog, you will learn the following. - What is Grafana Loki? - Grafana Loki Architecture - Grafana Loki Components - Loki Deployment Modes - Features of Grafana Loki - Difference Between Grafana Loki and EFK Stack - Example of How Chunks and Indexes are Stored in Loki 𝗗𝗲𝘁𝗮𝗶𝗹𝗲𝗱 𝗕𝗹𝗼𝗴: https://lnkd.in/gWBz-AAK Do you have any thoughts? Drop in the comment! 👉 Just last week, we have shared a detailed breakdown with a hands-on guide for this approach in my newsletter. → Sign up here (100% free): https://bit.ly/dcube-nl #devops #grafanaloki

128

1 comentario

When Kubernetes breaks, most teams go straight to Grafana. We open a terminal and run these 9 commands. Here’s the 9 command 𝐂𝐡𝐞𝐚𝐭𝐬𝐡𝐞𝐞𝐭 that saves us every week. 1. “𝐤𝐮𝐛𝐞𝐜𝐭𝐥 𝐠𝐞𝐭 𝐞𝐯𝐞𝐧𝐭𝐬 --𝐬𝐨𝐫𝐭-𝐛𝐲=.𝐦𝐞𝐭𝐚𝐝𝐚𝐭𝐚.𝐜𝐫𝐞𝐚𝐭𝐢𝐨𝐧𝐓𝐢𝐦𝐞𝐬𝐭𝐚𝐦𝐩” Your first stop. 90% of clues are hidden in event timing. Not in logs. Not in metrics. Right here. 2. “𝐤𝐮𝐛𝐞𝐜𝐭𝐥 𝐝𝐞𝐬𝐜𝐫𝐢𝐛𝐞 𝐩𝐨𝐝 <𝐩𝐨𝐝-𝐧𝐚𝐦𝐞>” The “why” behind the crash. We look for: OOMKilled, BackOff, FailedMount, ImagePull. 3. “𝐤𝐮𝐛𝐞𝐜𝐭𝐥 𝐠𝐞𝐭 𝐩𝐨𝐝𝐬 -𝐧 <𝐧𝐚𝐦𝐞𝐬𝐩𝐚𝐜𝐞> -𝐨 𝐰𝐢𝐝𝐞” Checks which node each pod’s on. Crucial when nodes are misbehaving silently. 4. “𝐤𝐮𝐛𝐞𝐜𝐭𝐥 𝐭𝐨𝐩 𝐩𝐨𝐝 --𝐜𝐨𝐧𝐭𝐚𝐢𝐧𝐞𝐫𝐬” We’ve caught so many memory leaks just by watching container-level spikes. 5. “𝐤𝐮𝐛𝐞𝐜𝐭𝐥 𝐥𝐨𝐠𝐬 <𝐩𝐨𝐝> -𝐜 <𝐜𝐨𝐧𝐭𝐚𝐢𝐧𝐞𝐫> --𝐩𝐫𝐞𝐯𝐢𝐨𝐮𝐬” The previous logs matter more than you think. Especially for crash loops, “--previous” is non-negotiable. 6. “𝐤𝐮𝐛𝐞𝐜𝐭𝐥 𝐠𝐞𝐭 𝐧𝐨𝐝𝐞𝐬 | 𝐠𝐫𝐞𝐩 𝐍𝐨𝐭𝐑𝐞𝐚𝐝𝐲” Don’t waste hours debugging pods when the node’s the issue. 7. “𝐤𝐮𝐛𝐞𝐜𝐭𝐥 𝐚𝐮𝐭𝐡 𝐜𝐚𝐧-𝐢” Works like magic when RBAC silently blocks access. (Especially in multi-team setups.) 8. “𝐤𝐮𝐛𝐞𝐜𝐭𝐥 𝐠𝐞𝐭 𝐞𝐧𝐝𝐩𝐨𝐢𝐧𝐭𝐬” Checks if services are even routing correctly. If this is empty, your pods might be fine. But your traffic’s going nowhere. 9. “𝐬𝐭𝐞𝐫𝐧 <𝐩𝐨𝐝-𝐧𝐚𝐦𝐞-𝐩𝐚𝐭𝐭𝐞𝐫𝐧> 𝐨𝐫 𝐤𝐮𝐛𝐞𝐭𝐚𝐢𝐥” Real-time logs across multiple pods. Absolute time-saver when you’re chasing down distributed bugs. These 9 commands won’t solve every problem. But they’ll show you where to look (fast.) That’s 90% of the battle in Kubernetes.

166

2 comentarios