Kathirvel M

Don't Miss to save the post - kubernetes new features launches in 2025 and learn the complete k8 here for free https://lnkd.in/drShEQAa Kubernetes introduced several significant new features and enhancements in 2025, especially with the upcoming v1.34 release scheduled for August 27, 2025. Here are the key highlights: Dynamic Resource Allocation (DRA) Graduation:  The DRA framework, which allows more flexible allocation of devices like GPUs or specialized hardware through structured resource claims, is moving to stable. This enables better management and sharing of advanced hardware in clusters. ServiceAccount Tokens for Image Pull Authentication:  Kubernetes is enhancing security by letting kubelets use short-lived, OIDC-compliant ServiceAccount tokens for authenticating image pulls—removing the need for long-lived secrets and aligning with best practices for workload identity. Pod Replacement Policy for Deployments:  A new .spec.podReplacementPolicy (alpha) gives you control over how pods are replaced during Deployment updates or scaling—choose faster rollouts or stricter resource control, addressing needs for clusters with tight resources or slow pod terminations. Production-Ready Tracing in Kubelet and API Server:  Deep tracing powered by OpenTelemetry is reaching stability for both kubelet and API servers. This enables operators to track events from control plane to node, crucial for debugging and performance tuning across distributed environments. Fine-Grained Autoscaling Control:  Horizontal Pod Autoscaler (HPA) now allows per-HPA configurable tolerance, letting you override the default autoscaling tolerance (10%) for individual workloads. This supports more responsive or conservative scaling, tailored to specific needs. KYAML Support (Kubernetes YAML Dialect):  KYAML, a stricter and less ambiguous subset of YAML optimized for Kubernetes, is being introduced. It offers safer syntax, always double-quotes string values, supports comments, allows trailing commas, and aims to reduce YAML’s classic error risks. kubectl will support KYAML output. Traffic Distribution Improvements for Services:  The Service resource adds new traffic distribution options, letting you prefer endpoints in the same zone or node, not just “close” ones. This enhances performance and availability in multi-zone or multi-node setups. Other broader 2025 trends include: AI-driven automation and better multi-cluster management Edge/IoT workflow optimizations Advanced security defaults and developer experience improvements 📍Register for free devops course - https://lnkd.in/drShEQAa [Classes starting from next week] 📍Download the syllabus - https://lnkd.in/daARkKq7 📍Join our DevOps Whatsapp group - https://lnkd.in/gJ4cvV77 Do make sure to share and like the post and follow Praveen Singampalli for more such content

244

21 Comments

☁️ Want to build secure AWS environments that scale with your organization? The AWS SRA provides the blueprint you need. Building secure AWS architectures isn't just about having multiple accounts - it's about organizing them properly with distinct responsibilities and security boundaries, since accounts provide the ultimate security boundary. The Security Reference Architecture (SRA) provides prescriptive guidance for implementing AWS security best practices through specialized Organizational Units (OUs) and dedicated account purposes: 🛡️ Management Account: Your most privileged account. Deploy as few tools in here and keep it locked down. Instead, deploy services/tools in other accounts or delegate administration. If compromised, you'll have a very bad week. 🔐 Security OU - Contains two critical accounts: + Security Tooling: Houses shared security tools like GuardDuty, CloudTrail, Security Hub, etc... + Log Archive: Centrally stores all security logs with strict access controls to ensure data integrity and durability. For example, this is where your CloudTrail logs get centralized 💻 Workloads OU: Where applications, EC2 instances, containers, etc... live 🌐 Infrastructure OU: + Network accounts: For managing shared VPCs, gateways, and firewalls + Shared Services: For resources used across your AWS environment (ie: Identity Center delegated admin) Remember, this is prescriptive guidance, not a rigid requirement. Your organization may need customizations based on specific use cases. ➡️ Looking to learn how to implement this? Enroll in our AWS Blue Team Learning Path: https://lnkd.in/gpFmabXi #AWSCertified #CloudSecurity #AWSSecuritySpecialty #CyberSecurity #AWS

111

It’s a common pattern. A few capable SREs or infra engineers start building out pipelines, provisioning scripts, and internal tooling. Before long, someone starts calling it a “platform.”  But when you take off the label, you find a handful of overburdened experts duct-taping critical workflows together with no shared roadmap, no service boundaries, and no time to think beyond immediate delivery. What makes a true platform team isn’t tooling expertise. It’s alignment on purpose and practice. Does your team have a clear definition of what internal DevEx actually means in your context? Do you have a shared mental model around service ownership, product thinking, and feedback loops? Do you know where the platform ends and app teams begin or are you stuck in a constant tug-of-war over support tickets and blurry responsibilities? Training helps you build that model. Not in abstract, but rooted in the real decisions your team makes every week: how to structure a golden path, how to define API contracts between dev and platform teams, how to version and evolve the platform like a product, not a static system. We bring your team through those frameworks together, so everyone in infra, dev, security, even management can speak the same language. And we don’t stop there. Through ongoing advisory, we stay close to your real problems. We pair with your tech leads. We evaluate decisions not just for technical soundness, but for cultural alignment and long-term sustainability. Because what you need isn’t just a more skilled team. You need a cohesive one, operating with clarity and purpose. That’s how platform transformations stick. If you’re curious about how that might look inside your org, explore the details here👉https://lnkd.in/dfTaZyAV

65

1 Comment

These are probably lesser-known Docker instructions. Do they matter when the image is used in Kubernetes? Let's understand. Most of us are familiar with common instructions like FROM, RUN, CMD, COPY, and EXPOSE, but there are other powerful yet lesser-known instructions: - SHELL - HEALTHCHECK - STOPSIGNAL - ONBUILD Let's understand how Kubernetes treats these when we run the image in pods. 𝗦𝗛𝗘𝗟𝗟: Changes the default shell in RUN instructions. In k8s, you need to explicitly configure the pod's command or args to change the shell, as Kubernetes bypasses the SHELL instruction from the Dockerfile. 𝗛𝗘𝗔𝗟𝗧𝗛𝗖𝗛𝗘𝗖𝗞: Checks if the container is functioning correctly. k8s ignores Docker HEALTHCHECK and uses its own probe mechanisms: Liveness, Readiness, and Startup Probes. 𝗦𝗧𝗢𝗣𝗦𝗜𝗚𝗡𝗔𝗟: Sets the system call signal to stop the container. In k8s, it sends a SIGTERM signal to all containers in the pod, regardless of the STOPSIGNAL specified in the Dockerfile. 𝗢𝗡𝗕𝗨𝗜𝗟𝗗: It's relevant only during image build time and does not affect runtime behavior in Kubernetes. So these instructions are primarily useful for standalone containers or when using Docker directly. We have published a blog explaining all these instructions with a practical example. 𝗗𝗲𝘁𝗮𝗶𝗹𝗲𝗱 𝗕𝗹𝗼𝗴: https://lnkd.in/gSbayK7V ---- If you're looking for such guides and tips, Subscribe to the blog and join 8000+ other DevOps engineers receiving our tips straight to their inbox! #devops #docker

495

20 Comments