Kubernetes makes container management easy, but networking can be hard. This guide explains how to set up proxy servers in a cluster. It covers managing traffic, improving security, and connecting services.

#kubernetes #courses #devops #infrastructure #learning

https://www.ofirc.com/kubernetes/networking/2025/03/28/setting-up-proxy-servers-in-kubernetes.html

#kubernetes #infrastructure #ithumor

🎒Google, Harvard, Microsoft and more are offering FREE AI courses with no payment required.

Here are 8 free courses to learn AI in 2025:

1. Introduction to Generative AI | Google
This is an introductory level microlearning course aimed at explaining what Generative AI is.
https://lnkd.in/eW5k4DVz

2. Microsoft's AI for Beginners
Microsoft's AI course starts with the basics and goes deeper. Learn about neural networks and deep learning as you progress.
🔗 https://lnkd.in/eKJ9qmEQ

3. Introduction to AI with Python
Harvard offers a 7-week course to explore AI concepts and algorithms.
Learn the tech behind AI and gain insights into machine learning libraries.
🔗 https://lnkd.in/dvHKidDp

4. Prompt Engineering for ChatGPT
Vanderbilt University offers a 6-module course for beginners on crafting effective prompts. Start with basics and learn how to get ChatGPT to work exactly how you want.
🔗 https://lnkd.in/d-rCb-AM

5. ChatGPT Prompt Engineering for Devs
OpenAI and DeepLearning present this course taught by Isa Fulford and Andrew Ng. Learn best practices and get hands-on experience with prompting.
🔗 https://lnkd.in/gtGc5Znp

6. LLMOps
Google Cloud and DeepLearning offer this course led by Erwin Huizenga. Master the LLMOps pipeline, train, and deploy your custom LLM.
🦾 https://lnkd.in/gMXDr7MJ

7. Big Data, Artificial Intelligence, and Ethics
UC Davis introduces big data and IBM’s Watson in this 4-module course. Learn about big data opportunities and AI’s limitations.
🔗 https://lnkd.in/gVEf3Dvm

8. AI Applications and Prompt Engineering
edX offers an intro course that goes beyond basic prompt engineering. Learn the basics and create your own AI applications.
🔗 https://lnkd.in/eyEVG4jD

#learning #freecources #ai

📚The "Software Engineering at Google" book is free to read online: https://abseil.io/resources/swe-book
#books #DevOps #infrastructure #SoftwareEngineering

The Kubecon London talk about Crossplane and v2
https://www.youtube.com/watch?v=6MrXcbcxnN4
#infrastructure #DevOps #video

How Kubernetes Works from Start to Finish ? 🛵

👣 1. You set up a Kubernetes cluster - it consists of a control plane and worker nodes.
2. You define your application using YAML files - typically with Deployment, Service, ConfigMap, etc.
3. You apply the YAML using kubectl apply -f, the request goes to the API Server, the central control point.
4. Kubernetes checks the request to decide what to do:
a). Create a new object like a Pod or Deployment?
b). Update or delete an existing object?
c). Trigger a controller to take action? etc.
5. The API server stores the object’s spec in etcd, the cluster’s database.
6. The appropriate controller sees the new spec - like a ReplicaSet controller watching for new Deployments.
7. The controller creates the necessary resources - for example, telling the scheduler to place new Pods.
8. The scheduler picks a suitable node for each Pod - based on resource availability and scheduling rules.
9. The Pod spec is sent to the node’s Kubelet - it requests the container runtime to start the container.
10. The container runtime pulls the image, creates the container, and runs it inside the Pod.
11. The CNI plugin assigns a network identity - the Pod gets an IP address and joins the cluster network.
12. kube-proxy sets up routing rules - allowing Services to forward traffic to healthy Pods.
13. The Kubelet reports Pod status back to the API server - used to track readiness and health.
14. If a Pod crashes or is deleted, the controller notices and recreates it - keeping the system in sync.
15. This entire loop keeps running - Kubernetes constantly watches and reconciles to match the desired state.

⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️

#infrastructure #devops #kubernetes

How tightly are your application code and CI/CD pipelines tied to a specific cloud or on-prem environment? While Kubernetes abstracts workload execution, other critical factors—such as infrastructure dependencies, service configurations, build processes, and deployment descriptors—can lock you into a single environment. This coupling limits flexibility, complicates migrations, and increases costs when adapting to new platforms, compliance requirements, or specialized technologies.

📺 In this video you can see the approach how standardize and decouple these elements, creating portable, reusable workflows that streamline CI/CD across diverse environments, enhance observability, and empower seamless transitions without vendor lock-in.

#DevOps #infrastructure #kubernetes #video
#Dapr #Crossplane #Dagger #ArgoCD

https://www.youtube.com/watch?v=PSenmCMU5mQ&t=48s

☀️Awesome DevOps MCP Servers Awesome☀️
A curated list of awesome Model Context Protocol (MCP) servers focused on DevOps tools and capabilities.

#DevOps #infrastructure #CloudComputing #ai

https://github.com/rohitg00/awesome-devops-mcp-servers

#humor #it

This article focus on Rust’s rise, technical advantages, and its role in shaping modern software development.

#rust #infrastructure #languages

https://blog.jetbrains.com/rust/2025/05/13/is-rust-the-future-of-programming/

#video #humor

#DevOps #infrastructure #humor

🚀 Modern CI/CD with Dagger, Argo CD, and Kubernetes!

This flexible architecture leverages Dagger for portable CI/CD pipelines, Argo CD for GitOps-driven deployments, and AWS EKS with Karpenter for dynamic scaling 🧨

* Run pipelines in containers for isolation and portability.
* Automate infrastructure with Git as the single source of truth.
* Scale efficiently with ephemeral Dagger Engines and Karpenter.
* Integrate seamlessly with GitHub via Actions Runner Controller.

Cost-effective and cloud-native, it optimizes resources and supports modern DevOps.

#CICD #GitOps #Kubernetes #DevOps

https://dagger.io/blog/argo-cd-kubernetes

Hello, awesome folks of the interwebs! 😎 Curious about who's behind the keyboard, churning out these spicy posts? It's just me, your friendly neighborhood DevOps engineer, slinging code and automating chaos at a pretty famous company (no big deal, right? 😜). This channel started as my personal stash for epic tips, tricks, and brain-meltingly useful info that helps me streamline processes and make life easier for companies building the coolest projects in the galaxy. 🚀

Stick around, because I’m cooking up a storm of mind-blowingly helpful content—think automation hacks, DevOps wizardry, and maybe a few memes to keep it real. Expect a wild ride of useful, quirky, and downright awesome posts that’ll level up your tech game! 🎉 Hit that follow button, and let’s make some magic together! ✨ #DevOpsLife #AutomateAllTheThings

#humor #it

#humor #ai

🚀 Ever wonder how a packet actually travels inside Amazon EKS?

This detailed session will walk you through each step of a packet's journey in Amazon EKS:

🐛 Pod-to-Pod Traffic on the Same Node: Explore veth pair communication and routing table intricacies.

🧩 Cross-Node Networking: See how SNAT and DNAT come into play when pods talk across nodes in a subnet.

🌐 Ingress Flow: Follow a packet from a Route 53 lookup, through the Internet Gateway, ALB, ENI, and into the public subnet.

📡 Service Types Uncovered: Understand how ClusterIP, NodePort, and LoadBalancer differ at OSI Layer 4 in real-world EKS setups.

If you run EKS or just want to truly understand Kubernetes networking, this is a must-watch. 🎯

🎥 Watch the talk now
https://www.youtube.com/watch?v=LZahLhuuxSQ

#AWS #EKS #Kubernetes #Networking #CloudNative

Imagine CQRS as the over-caffeinated coder who insists on reading AND writing data at the speed of light, while Microservices are like that friend who splits the group project into a million tiny tasks—total chaos but somehow it works! Event-Driven? That’s the guy who reacts to every ping like it’s a party invite.

#DevOps #Architecture #application

💡 Using AWS EKS? Watch out - cross-AZ control plane traffic might hit your wallet 💸

Yes - even inside the same AWS region, some traffic can be billed and other clouds are in the same situation. These costs are often hard to detect, and it's tricky to know which traffic you're paying for or who's generating it.
Let’s take a closer look at when and why this happens - and how the EKS architecture plays into it 👉

https://docs.aws.amazon.com/images/eks/latest/best-practices/images/reliability/eks-data-plane-connectivity.jpeg

🧱 Understanding the EKS Control Plane
To get to the root of the issue, we first need to understand how Amazon EKS sets up its control plane. By default, the EKS control plane is distributed across two Availability Zones (e.g., AZ A and AZ B), even when there's no load yet on the cluster. Meanwhile, when you create your cluster, you likely spread your worker nodes (like managed node groups or Karpenter node pools) across three Availability Zones for high availability - something AWS strongly recommends for reliability.

🧮 When Traffic is Free - and When It’s Not
Here’s where cost comes in. According to AWS:
Traffic within the same Availability Zone is free
Traffic between different Availability Zones, even in the same region, is billed
So, what does this mean in practice?
💰 Pods in AZ A communicating with the control plane in AZ A = ✅ free
💰 Pods in AZ B communicating with the control plane in AZ B = ✅ free
But...
💳 Pods in AZ C trying to talk to the control plane (which only exists in AZ A and B) = 💸 paid inter-AZ traffic

This kind of traffic might happen frequently - especially for workloads that constantly interact with the Kubernetes API server (like CI/CD tools, controllers, or operators), and there may also be work on the Amazon side, for example, rolling out patches to the control plane, which will lead to a change in zones for the control plane servers.

🛠 How to Reduce Inter-AZ Costs
To avoid or minimize these charges:
☘️ Align your worker node placement with control plane AZs (e.g., only use AZ A and B if cost is a concern)
☘️ Pin high-frequency API consumers (e.g., system pods or controllers) to AZs where the control plane resides
☘️ Use VPC Flow Logs + Athena or CloudWatch, KubeCost, CloudWatch + Usage Reports with Athena, CostExplorer, AWS CUR (Cost and Usage Report) with Athena or QuickSight(Cudos dashboards), or custom metrics to monitor traffic patterns.

Of course, I don’t think that with the increase in loads you will encounter this problem, since the control plane is automatically scaled and you will be in all availability zones. But it's good to have knowledge in this area and understanding these details can help you make better architecture choices - and avoid surprise costs ☀️

If you have any cool ways to find network traffic prices by source that I didn't list above, please share them in the comments 🤑

#aws #eks #network #AmazonEKS #CloudNative
#CloudCosts #AWSBilling #FinOps #InterAZTraffic
#AWSNetworking #DevOps #SRE #Observability

🚨Running Aws EKS in production is not just about launching a cluster !

😶It’s about engineering for scale, reliability, and application-specific behavior and that only comes with real production experience.
Creating effective solutions based on AWS EkS requires deep production experience. It’s not enough to "spin up a cluster"- you must design, adapt, and operate for real workloads.

Good cloud services are just a set of tools, to create good architectural solutions for applications and then their excellent performance to work on a global scale, you need cool engineers who have experience with such tools🧑‍💻

Here is a good article confirming my words: https://engineering.probo.in/production-grade-pain-lessons-from-scaling-kubernetes-on-eks-03571838c7a3

#K8s #AmazonEKS #application #architecture #infrastructure
#Kubernetes #CloudComputing #DevOps #CloudArchitecture #SiteReliabilityEngineering #ProductionReady #InfrastructureAsCode #CloudNative #SRE #Observability #PlatformEngineering #Scalability