Igor Guedes’ Post

🚀 Introducing: Sloth Kubernetes - Simplified Multi-Cloud Deployment! 🦥 Excited to share my new open-source project: a CLI tool that revolutionizes Kubernetes cluster deployment across multiple clouds! 🌐 🎯 THE PROBLEM: ❌ Multiple tools (Pulumi CLI, Terraform, kubectl...) ❌ Manual VPN configuration between clouds ❌ Conflicting dependencies ❌ Steep learning curve ✨ THE SOLUTION - Sloth Kubernetes: ✅ ONE single binary - zero dependencies! ✅ Automated deployment: VPC + VPN + Kubernetes ✅ Multi-cloud native (DigitalOcean + Linode) ✅ Automatic WireGuard VPN mesh ✅ GitOps-ready with ArgoCD ✅ Embedded Pulumi Automation API 🔥 HIGHLIGHTS: • Go 1.23+ with modular architecture • RKE2 Kubernetes + CIS compliance • Automatic mesh networking • Kubernetes-style YAML config • 46.1% test coverage 💡 WHY MULTI-CLOUD? 🛡️ HA - survives provider outages 💰 Cost optimization 🌍 Geographic distribution 🔄 Zero vendor lock-in ⚡ EXAMPLE: ```bash git clone https://lnkd.in/dtKNCj5X go build -o sloth-kubernetes sloth-kubernetes deploy --config cluster.yaml sloth-kubernetes kubeconfig > ~/.kube/config # Cluster running in 8 minutes! ⚡ ``` 🎨 ARCHITECTURE (3 phases): 1️⃣ VPC Creation - isolated networks 2️⃣ WireGuard VPN - encrypted mesh 3️⃣ Kubernetes - automated RKE2 Everything in ONE command! 🚀 📊 USE CASES: • Startups needing HA without complexity • DevOps teams seeking automation • Companies avoiding vendor lock-in • Multi-region/multi-cloud projects 📚 RESOURCES: 🌟 GitHub: https://lnkd.in/dtKNCj5X 📖 1,200+ lines of docs with 9 ASCII diagrams 💻 Examples: minimal, multi-cloud, enterprise 🔧 10+ documented CLI commands 🎓 LEARNINGS: • Pulumi Automation API is amazing for embedding • WireGuard simplifies multi-cloud networking • Go is perfect for robust CLIs • Visual documentation is essential 💭 ROADMAP: • AWS, GCP, Azure support • Node autoscaling • Web UI dashboard • Monitoring stack 🤝 100% open-source (MIT)! PRs welcome! ⭐ 👨💻 For Devs/SREs/Platform Engineers: This tool will save you HOURS of manual config. Try it and let me know! Feedback? Want to contribute? Comment below! 👇 #DevOps #SRE #Kubernetes #CloudNative #MultiCloud #Golang #OpenSource #InfrastructureAsCode #GitOps #PlatformEngineering #CloudEngineering #RKE2 #WireGuard #Pulumi #ArgoCD

🦥 Launch: Sloth Kubernetes - Multi-Cloud Deploy Simplified Just launched a CLI tool that makes multi-cloud Kubernetes deployment ridiculously simple! 🎯 The Problem: Multi-cloud Kubernetes deployment = headache • Multiple CLIs (Pulumi, Terraform, kubectl...) • Manual VPN setup between clouds • Complex networking configuration • Weeks to production 🦥 The Solution: One binary. One command. One multi-cloud cluster. ✨ Features: ✅ Zero Dependencies - Embedded Pulumi API (no CLI!) ✅ Multi-Cloud - DigitalOcean + Linode ✅ Automatic VPN - WireGuard mesh self-configured ✅ K3s Kubernetes - Lightweight and production-ready ✅ GitOps - Automatic ArgoCD bootstrap ⚡ Example: ```yaml spec:  providers:   digitalocean:    enabled: true   linode:    enabled: true  network:   wireguard:    create: true # 🦥 Automatic VPN!  nodePools:   - name: masters    count: 3    roles: [master] ``` ```bash sloth-kubernetes deploy --config cluster.yaml # 10 min later: HA cluster ready! 🦥 ``` 🔐 Security by Default: • Encrypted WireGuard VPN • Secrets encryption • CIS benchmarks • Private VPCs 💰 Cost: • Dev: ~$15/month • Production HA: ~$200/month • Open source! 🌍 Why Multi-Cloud? • No vendor lock-in • Geographic HA • Better cost-performance • Redundancy 🎓 Tech Stack: Go 1.23 • Pulumi Automation API • K3s • WireGuard • 90%+ coverage Why "Sloth"? 🦥 We do things slowly and correctly. Good clusters take time! Open source project on GitHub. Contributions welcome! https://lnkd.in/dtKNCj5X #Kubernetes #DevOps #MultiCloud #OpenSource #K3s #CloudNative #GoLang #SRE 🦥 Slow and steady!

🥵 “I chose the hard way. And Kubernetes made sure I felt it.” I could’ve spun up a managed cluster EKS, AKS, GKE — one click and done. -But no, I wanted to earn it. -A real, bare-metal, kubeadm-driven Kubernetes cluster — the hard way. Because DevOps isn't about shortcuts. It's about understanding what the shortcuts are hiding. So I rolled up my sleeves and built it myself. 🕐 2:08 AM — The POC That Turned Into a War Story Control plane — up ✅ Etcd — healthy ✅ Worker nodes — joined ✅ Pods — running ✅ I stared at the terminal like a proud parent. “I did it.” Then came the test. Simple service call. Connection timed out. Ping pod 👉 fails DNS query 👉 fails Cross-node traffic 👉 nope Everything looked right but nothing worked. I debugged kubelet, checked ports, restarted services even questioned my Linux skills at one point 😅 Then — while scrolling logs — destiny hit: No CNI configuration file found In that moment, I realized… I built a town. But forgot the roads. 🧠 What I Learned Kubernetes will schedule pods. It will pretend everything is healthy. But networking? That’s #CNI's kingdom. CNI gives: Pod IPs Routing between nodes Network policy enforcement Overlay/underlay networking DNS + service traffic flow Without CNI, Kubernetes is like creating microservices on different planets 🌑🪐 Everything exists, but nothing connects. After installing #WeaveNet, traffic flowed, services spoke, dashboards calmed. And I slept like someone who'd just passed a boss fight. 🛠️ My Cluster Build Checklist Now 1️⃣ Install Kubernetes components 2️⃣ Install CNI before celebrating 3️⃣ Validate cross-node pod communication 4️⃣ Test service & DNS resolution 5️⃣ Apply baseline NetworkPolicies A running pod means nothing. A communicating pod means everything. ✨ You don't truly understand Kubernetes until you break it — and fix it — with your own hands. 🌐 Pods need a CNI to talk 🛠️ Kubernetes delegates networking — it doesn't do it 🛡️ NetworkPolicies are not optional 🧠 DIY cluster builds teach lessons cloud consoles never will 💬 Your Turn Have you ever gone “Kubernetes hard way”? What broke first for you — networking, certificates, kubelet, or your patience? 😅 #Kubernetes #CNI #CloudNative #SRE #DevOpsJourney #K8sNetworking

🚨 𝗜𝗻𝗴𝗿𝗲𝘀𝘀 𝗡𝗴𝗶𝗻𝘅 𝗜𝘀 𝗥𝗲𝘁𝗶𝗿𝗶𝗻𝗴 — 𝗪𝗵𝗮𝘁 𝗗𝗲𝘃𝗢𝗽𝘀 & 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝘀 𝗦𝗵𝗼𝘂𝗹𝗱 𝗞𝗻𝗼𝘄 Today I came across an important update in the Kubernetes ecosystem, and I felt it’s something every DevOps/Cloud/K8s engineer should be aware of. The 𝗰𝗼𝗺𝗺𝘂𝗻𝗶𝘁𝘆-𝗺𝗮𝗶𝗻𝘁𝗮𝗶𝗻𝗲𝗱 𝗜𝗻𝗴𝗿𝗲𝘀𝘀 𝗡𝗚𝗜𝗡𝗫 (the one most people install directly from the official Kubernetes docs) is officially moving into deprecation. 🔻 𝗪𝗵𝗮𝘁 𝘁𝗵𝗶𝘀 𝗺𝗲𝗮𝗻𝘀  • No new releases after 𝗠𝗮𝗿𝗰𝗵 𝟮𝟬𝟮𝟲  • No bug fixes, security patches, or updates  • The project will be archived  • Only option will be self-maintenance via a fork — which is not practical for most teams 🔧 𝗪𝗵𝘆 𝗶𝘀 𝘁𝗵𝗶𝘀 𝗵𝗮𝗽𝗽𝗲𝗻𝗶𝗻𝗴? Simply put — 𝗹𝗮𝗰𝗸 𝗼𝗳 𝗺𝗮𝗶𝗻𝘁𝗮𝗶𝗻𝗲𝗿𝘀. A massively used project was being handled by just 1–2 contributors for years. This highlights a real challenge in open-source: people want to contribute, but very few can commit the time required to maintain large projects. 🟦 𝗜𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁 𝗖𝗹𝗮𝗿𝗶𝗳𝗶𝗰𝗮𝘁𝗶𝗼𝗻 There are two different NGINX ingress controllers (many people don’t realize this): 1️⃣ 𝗜𝗻𝗴𝗿𝗲𝘀𝘀 𝗡𝗚𝗜𝗡𝗫 – maintained by Kubernetes community (this one is deprecated) 2️⃣ 𝗡𝗚𝗜𝗡𝗫 𝗜𝗻𝗴𝗿𝗲𝘀𝘀 𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗲𝗿 𝗯𝘆 𝗡𝗚𝗜𝗡𝗫/𝗙𝟱 – maintained by the vendor (❗not deprecated) If you installed your ingress controller via 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝗱𝗼𝗰𝘀, you are impacted. If you installed via 𝗡𝗚𝗜𝗡𝗫 𝗼𝗳𝗳𝗶𝗰𝗶𝗮𝗹 𝗱𝗼𝗰𝘀/𝗛𝗲𝗹𝗺 𝗰𝗵𝗮𝗿𝘁, you are not. 🛠️ 𝗪𝗵𝗮𝘁 𝘀𝗵𝗼𝘂𝗹𝗱 𝘆𝗼𝘂 𝗱𝗼 𝗻𝗲𝘅𝘁? Depending on your setup, you have multiple options: ✔️ 𝗠𝗶𝗴𝗿𝗮𝘁𝗲 𝘁𝗼 𝗚𝗮𝘁𝗲𝘄𝗮𝘆 𝗔𝗣𝗜 (future of Kubernetes traffic management) ✔️ Use the vendor-maintained 𝗡𝗚𝗜𝗡𝗫 𝗜𝗻𝗴𝗿𝗲𝘀𝘀 𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗲𝗿 ✔️ Switch to alternatives like 𝗧𝗿𝗮𝗲𝗳𝗶𝗸, 𝗞𝗼𝗻𝗴, 𝗛𝗔𝗣𝗿𝗼𝘅𝘆, 𝗲𝘁𝗰. This change will impact many Kubernetes environments, so it’s better to plan ahead rather than scramble in 2026. If you’re working in DevOps, Cloud, or handling Kubernetes clusters — definitely keep this on your radar. Happy & Fun Learning! Suyash Kesharwani #Kubernetes #DevOps #CloudComputing #NGINX #IngressController #GatewayAPI #Containers #SRE #K8sCommunity #OpenSource #TechUpdates

Docker Internals, Explained in 14 Simple Points I’ve broken down exactly how Docker works under the hood ,from build to run, layers, namespaces, cgroups, networking, volumes, caching, everything. Most engineers use Docker every day… But very few know what’s actually happening inside. So I made a simple list anyone can understand. 👉 Here’s the full breakdown: 1. When you run docker build, Docker reads the Dockerfile line by line. It uses your current folder as the build context. 2. Each line in the Dockerfile creates a new image layer. These layers are saved as compressed files inside Docker’s storage. 3. Docker uses a union filesystem like OverlayFS. It stacks all layers to form a single container filesystem. 4. When you run docker run, Docker takes the image and adds a writable layer on top. This becomes your container. 5. The container is just a process on your machine. It runs with its own isolated environment using Linux namespaces and cgroups. 6. Namespaces isolate process ID, hostname, network, mount points, and shared memory. Cgroups control CPU, RAM, and I/O usage. 7. Docker gives the container a virtual Ethernet interface. By default, it’s connected to the docker0 bridge. 8. If you use -p to map ports, Docker sets up iptables rules. This forwards traffic from your host to the container. 9. The Docker daemon (dockerd) runs in the background. It handles builds, containers, images, volumes, and networks. 10. The Docker CLI talks to the daemon using a REST API. It connects over a Unix socket or TCP. 11. Docker volumes live outside the container layer. They’re stored in /var/lib/docker/volumes and survive container restarts. 12. Any change inside the container is temporary. If you delete the container, the changes are gone unless saved to a volume or image. 13. Docker uses content-based hashes for layers. This makes layers reusable, cacheable, and easy to share. 14. When you push an image, Docker checks which layers are already in the registry. It only uploads what’s missing. Explore my DevOps Journey https://lnkd.in/dAfC4yWs What do we cover: DevOps, Cloud, Kubernetes, IaC, GitOps, MLOps Follow Sainathh Shivaji Mitalakar for more… 🔁 Consider a Repost if this is helpful  

🚀 sloth-kubernetes: Multi-Cloud Kubernetes in a Single Binary Tool that unifies Pulumi + Salt + kubectl + Helm + Kustomize, eliminating external dependencies for production-grade Kubernetes. 💎 FIVE TOOLS IN ONE • Pulumi Automation API (IaC without external CLI) • Salt API Client (100+ remote operations) • Complete kubectl - zero dependencies, works offline! • Helm v3 wrapper - all chart operations • Kustomize wrapper - full config customization ☁️ TRUE MULTI-CLOUD: DigitalOcean, Linode, Azure (AWS/GCP coming) ⚙️ 50+ CLI COMMANDS Deploy: deploy, destroy, status, validate (dry-run/auto-approve) Nodes: list, add, remove, ssh, upgrade VPN: status, peers, config, test, join Salt: 100+ ops (commands, packages, services, Docker, K8s) GitOps: ArgoCD bootstrap, addons kubectl: all native commands helm: install, upgrade, repo, search, list kustomize: build, edit, create Stacks: multi-environment, state management 🔐 SECURITY • Bastion + MFA + SSH audit • Encrypted WireGuard VPN mesh • Private nodes (no public IPs) • RBAC, Network Policies, TLS, CIS compliance 🌐 NETWORKING • Per-provider VPC + WireGuard mesh • Automatic DNS (DO/Cloudflare/Route53) • Load Balancers + NGINX Ingress • CNI: Calico/Cilium/Flannel 🏗️ ORCHESTRATION: 8 Automated Phases SSH keys → Bastion → VPCs → WireGuard → Nodes → RKE2 → VPN config → DNS ✨ ENTERPRISE KUBERNETES • RKE2 + security hardening • HA with odd-number masters • Automatic etcd backups • Zero-downtime rolling updates 🎯 EXAMPLE ```bash # Multi-cloud deploy sloth-kubernetes deploy --config cluster.yaml # Salt on workers sloth-kubernetes salt cmd "systemctl status kubelet" --target "worker*" # Add nodes sloth-kubernetes nodes add --pool workers --count 2 # Native kubectl sloth-kubernetes kubectl get pods -A # Helm charts sloth-kubernetes helm install nginx bitnami/nginx # Kustomize configs sloth-kubernetes kustomize build ./overlays/prod ``` 📊 STATS: 15,500+ Go lines | 50+ commands | 100+ Salt ops | 6 platforms 🔮 USE CASES ✅ Local dev (minimal cost) ✅ Multi-cloud staging ✅ Distributed production HA ✅ Disaster recovery ✅ Cost optimization 🔗 https://lnkd.in/dtKNCj5X 💻 Go | Pulumi | Salt | kubectl | Helm | Kustomize | RKE2 | WireGuard #Kubernetes #MultiCloud #DevOps #InfrastructureAsCode #CloudNative #RKE2 #WireGuard #Golang #OpenSource #SRE #GitOps #Helm #Kustomize

Kubernetes isn’t just a tool, it’s a spectrum.   I mapped 8 cluster types, from local dev to air-gapped HA to global federation. If you’ve only used EKS/AKS/GKE, this post will expand your mental model. #Kubernetes #SystemDesign #SystemArchitecture #DevOps #Infrastructure #Kubeadm #RKE2 #CloudNative #K3s #HAClusters #EdgeComputing

I'm a firm believer in spending 10 hours automating a 10-minute job. Why? Because the payoff is a scalable, repeatable, and error-proof system. In Part 4 of my "On-Premise 101" series, I'm tackling the manual work of building a Kubernetes cluster. Instead of clicking around in a UI, I'm using Terraform to provision all 12 of my Proxmox VMs with a single command. I'm sharing my complete Infrastructure as Code (IaC) setup, which is built just like a professional environment: - Remote State: Using Minio (S3-compatible) to safely store my state file. - Environment Separation: Keeping my dev and prod variables (.tfvars) and backends separate. - Dynamic Inventory: A simple JSON file defines all my cluster nodes. - Reusable Modules: A "VM factory" module to build each machine. I can now spin up, destroy and recreate the whole cluster in minutes. That's the power of IaC. Check out the full guide and code here. https://lnkd.in/g-fpKeDs #Terraform #IaC #Proxmox #Kubernetes #Automation #SysAdmin #DevOps #Homelab #Minio

🚀 Introducing sloth-kubernetes: Multi-Cloud Kubernetes Made Simple I'm excited to share sloth-kubernetes - a CLI tool that simplifies multi-cloud Kubernetes deployment with RKE2 and WireGuard VPN mesh networking. 🎯 What makes it unique? Single Binary, Full Power: • Embedded Pulumi Automation API (no external CLI needed) • Embedded Salt API Client (100+ operations) • Embedded kubectl (full K8s management) • ~317MB binary with everything included ☁️ True Multi-Cloud Support: • DigitalOcean, Linode, and Azure (AWS/GCP coming soon) • Deploy hybrid clusters across multiple clouds • Unified management interface 🔒 Built-in Security: • WireGuard VPN mesh for private cluster communication • Automatic bastion host deployment for secure SSH access • Cross-cloud private networking ⚡ Simple YAML Configuration: Deploy a 3-master, 3-worker multi-cloud cluster in minutes with a simple config file. The tool handles everything: provisioning, networking, VPN mesh, and Kubernetes installation. ✨ Why these architectural choices? • Embedded tools = zero external dependencies, consistent behavior • RKE2 = production-grade Kubernetes with built-in security hardening • WireGuard = high-performance VPN with modern cryptography • Infrastructure as Code = reproducible, version-controlled deployments 📊 Current Status: ✅ Production-ready core features ✅ Comprehensive test coverage (14.7%) ✅ Multi-cloud provider support ✅ Automated CI/CD pipeline ✅ Extensive documentation 🔮 What's Next: • AWS and GCP provider support • Enhanced monitoring and observability • Cluster upgrade automation • Disaster recovery features • Helm chart management 📈 Key Stats: • 15,332+ lines of code • 100+ Salt API operations • 6 build platforms (darwin/linux/windows × amd64/arm64) • Open source and ready for contributions 🔗 GitHub Repository: https://lnkd.in/dtKNCj5X The project is open source and contributions are welcome! If you're interested in multi-cloud Kubernetes deployment or infrastructure automation, I'd love to hear your thoughts and feedback. 💻 Tech Stack: Go, Pulumi, Salt, kubectl, RKE2, WireGuard, GitHub Actions #Kubernetes #MultiCloud #DevOps #InfrastructureAsCode #CloudNative #RKE2 #WireGuard #Golang #OpenSource #SRE #CloudComputing #ContainerOrchestration

☸️ Kubernetes Ingress: Unlocking Advanced Traffic Management! 🌐 "How do I route external traffic to my K8s services without a mess of LoadBalancers?" 🤔 In DevOps, managing external access to multiple services in Kubernetes often leads to scattered LoadBalancer resources, security gaps, and complex URL routing—challenging scalability in 2025’s cloud-native era. ⚠️ The Problem: Pre-Ingress Traffic Challenges Without Ingress, teams faced: Multiple LoadBalancers: One per service, inflating costs and complexity. Limited Routing: Basic path or hostname routing required manual hacks. Security Risks: Exposed ports lacked TLS termination natively. Scalability Limits: Adding services meant reconfiguring each LoadBalancer. No Centralized Control: Traffic policies were fragmented across clusters. This inefficiency slowed deployments in production environments. 💡 Ingress: The Solution for Smart Traffic Handling Ingress provides a single entry point for external traffic, managed via an Ingress Controller (e.g., NGINX, Traefik). Key features: Host & Path Routing: Direct traffic (e.g., app1.example.com/api to Service A). TLS Termination: Secure connections with Let’s Encrypt integration. Load Balancing: Distributes traffic across pods efficiently. Annotations: Fine-tune behaviors like rate limiting or redirects. Example: An Ingress resource: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress spec: rules: - host: app.example.com http: paths: - path: /api pathType: Prefix backend: service: api-service port: 80 tls: - hosts: [app.example.com] Apply with kubectl—traffic routes securely and scalably! 🔄 How Ingress Operates: Define Ingress: Create a resource with rules for hosts/paths. Deploy Controller: Install NGINX or similar to process rules. Route Traffic: External requests hit the controller, directed to Services. Manage Security: Apply TLS and policies dynamically. Scale: Adjust pod counts as traffic grows. This centralized approach simplifies multi-service access. 📊 Ingress’ Transformative Benefits: Cost Efficiency: Replaces multiple LoadBalancers—crucial with 2025’s 35% K8s growth. Flexibility: Supports complex routing for microservices. Security: Native TLS and WAF integration bolster defenses. Scalability: Handles millions of requests with ease. Centralization: Single point to manage traffic policies. 🌟 Why Ingress is K8s’ Traffic Game-Changer As of October 20, 2025, 04:43 PM PKT, Ingress powers 40% of K8s traffic management. It’s a must for advanced DevOps pros. Struggling with K8s routing? Share your insights below! 👇 #Kubernetes #DevOps #Ingress #K8s #CloudNetworking