Explore the newly released Kubernetes 1.29 which introduces updates to volume attributes and enhances class processing. This release aims to streamline resource allocation and management for users. The update includes detailed improvements and best practices for practitioners.

The v1. 29 release of Kubernetes introduced an alpha feature to support modifying a volume by changing the volumeAttributesClassName that was specified for a PersistentVolumeClaim (PVC). With the feature enabled, Kubernetes can handle updates of volume attributes other than capacity. Allowing volume attributes to be changed without managing it through different provider ' s APIs directly simplifies the current flow. You can read about VolumeAttributesClass usage details in the Kubernetes documentation or you can read on to learn about why the Kubernetes project is supporting this feature. VolumeAttributesClass The new storage. K8s. Io/v1alpha1 API group provides two new types: VolumeAttributesClass Represents a specification of mutable volume attributes defined by the CSI driver. The class can be specified during dynamic provisioning of PersistentVolumeClaims, and changed in the PersistentVolumeClaim spec after provisioning. ModifyVolumeStatus Represents the status object of ControllerModifyVolume operation. With this alpha feature enabled, the spec of PersistentVolumeClaim defines VolumeAttributesClassName that is used in the PVC. At volume provisioning, the CreateVolume operation will apply the parameters in the VolumeAttributesClass along with the parameters in the StorageClass. When there is a change of volumeAttributesClassName in the PVC spec, the external-resizer sidecar will get an informer event. Based on the current state of the configuration, the resizer will trigger a CSI ControllerModifyVolume. More details can be found in KEP-3751. How to use it If you want to test the feature whilst it ' s alpha, you need to enable the relevant feature gate in the kube-controller-manager and the kube-apiserver. Use the --feature-gates command line argument: --feature-gates= . . . , VolumeAttributesClass=true It also requires that the CSI driver has implemented the ModifyVolume API. User flow If you would like to see the feature in action and verify it works fine in your cluster, here ' s what you can try: Define a StorageClass and VolumeAttributesClass apiVersion: storage. K8s. Io/v1 kind: StorageClass metadata: name: csi-sc-example provisioner: pd. Csi. Storage. Gke. Io parameters: disk-type:  hyperdisk-balanced volumeBindingMode: WaitForFirstConsumer apiVersion: storage. K8s. Io/v1alpha1 kind: VolumeAttributesClass metadata: name: silver driverName: pd. Csi. Storage. Gke. Io parameters: provisioned-iops:  3000 provisioned-throughput:  50 Define and create the PersistentVolumeClaim apiVersion: v1 kind: PersistentVolumeClaim metadata: name: test-pv-claim spec: storageClassName: csi-sc-example volumeAttributesClassName: silver accessModes: - ReadWriteOnce resources: requests: storage: 64Gi Verify that the PersistentVolumeClaim is now provisioned correctly with: kubectl get pvc Create a new VolumeAttributesClass gold: apiVersion: storage. K8s. Io/v1alpha1 kind: VolumeAttributesClass metadata: name: gold driverName: pd. Csi. Storage. Gke. Io parameters: iops:  4000 throughput:  60 Update the PVC with the new VolumeAttributesClass and apply: apiVersion: v1 kind: PersistentVolumeClaim metadata: name: test-pv-claim spec: storageClassName: csi-sc-example volumeAttributesClassName: gold accessModes: - ReadWriteOnce resources: requests: storage: 64Gi Verify that PersistentVolumeClaims has the updated VolumeAttributesClass parameters with: kubectl describe pvc &lt; PVC_NAME&gt; Next steps See the VolumeAttributesClass KEP for more information on the design You can view or comment on the project board for VolumeAttributesClass In order to move this feature towards beta, we need feedback from the community, so here ' s a call to action: add support to the CSI drivers, try out this feature, consider how it can help with problems that your users are having… Getting involved We always welcome new contributors. So, if you would like to get involved, you can join our Kubernetes Storage Special Interest Group (SIG). If you would like to share feedback, you can do so on our public Slack channel. Special thanks to all the contributors that provided great reviews, shared valuable insight and helped implement this feature (alphabetical order): Baofa Fan (calory) Ben Swartzlander (bswartz) Connor Catlett (ConnorJC3) Hemant Kumar (gnufied) Jan Šafránek (jsafrane) Joe Betz (jpbetz) Jordan Liggitt (liggitt) Matthew Cary (mattcary) Michelle Au (msau42) Xing Yang (xing-yang)

Kubernetes 1.29: VolumeAttributesClass for Volume Modification

"Unveiling DevOps Breakthroughs: From Kubernetes to ETL"

Issue %%issue_number%%

Microsoft announces enhanced enterprise trust in its Azure OpenAI Service by introducing data zones, fortifying data residency, and enabling greater control over customer data. This initiative aims to further solidify Azure's capability in securely deploying and managing AI solutions. Customers can now more selectively manage where their data resides, aligning with data sovereignty requirements.

Announcing new features designed to further enhance data privacy and security capabilities for customers building and scaling with Azure OpenAI. The post Enterprise trust in Azure OpenAI Service strengthened with Data Zones appeared first on Microsoft Azure Blog.

Enterprise trust in Azure OpenAI Service strengthened with Data Zones

"Unlock Cloud Secrets: DevOps Trends & AI Insights"

This article provides an overview of recent updates and initiatives by the Kubernetes Special Interest Group for Architecture. It highlights key enhancements in the project, focusing on improved code quality and architecture decisions aimed at maintaining Kubernetes' high performance and scalability. Developers and architects can gain insights into the strategic direction and technical considerations influencing Kubernetes' ongoing evolution.

This is the third interview of a SIG Architecture Spotlight series that will cover the different subprojects. We will cover SIG Architecture: Code Organization. In this SIG Architecture spotlight I talked with Madhav Jivrajani (VMware), a member of the Code Organization subproject. Introducing the Code Organization subproject Frederico (FSM): Hello Madhav, thank you for your availability. Could you start by telling us a bit about yourself, your role and how you got involved in Kubernetes? Madhav Jivrajani (MJ): Hello! My name is Madhav Jivrajani, I serve as a technical lead for SIG Contributor Experience and a GitHub Admin for the Kubernetes project. Apart from that I also contribute to SIG API Machinery and SIG Etcd, but more recently, I’ve been helping out with the work that is needed to help Kubernetes stay on supported versions of Go, and it is through this that I am involved with the Code Organization subproject of SIG Architecture. FSM: A project the size of Kubernetes must have unique challenges in terms of code organization -- is this a fair assumption? If so, what would you pick as some of the main challenges that are specific to Kubernetes? MJ: That’s a fair assumption! The first interesting challenge comes from the sheer size of the Kubernetes codebase. We have ≅2. 2 million lines of Go code (which is steadily decreasing thanks to dims and other folks in this sub-project!), and a little over 240 dependencies that we rely on either directly or indirectly, which is why having a sub-project dedicated to helping out with dependency management is crucial: we need to know what dependencies we’re pulling in, what versions these dependencies are at, and tooling to help make sure we are managing these dependencies across different parts of the codebase in a consistent manner. Another interesting challenge with Kubernetes is that we publish a lot of Go modules as part of the Kubernetes release cycles, one example of this is client-go. However, we as a project would also like the benefits of having everything in one repository to get the advantages of using a monorepo, like atomic commits. . . So, because of this, code organization works with other SIGs (like SIG Release) to automate the process of publishing code from the monorepo to downstream individual repositories which are much easier to consume, and this way you won’t have to import the entire Kubernetes codebase! Code organization and Kubernetes FSM: For someone just starting contributing to Kubernetes code-wise, what are the main things they should consider in terms of code organization? How would you sum up the key concepts? MJ: I think one of the key things to keep in mind at least as you’re starting off is the concept of staging directories. In the kubernetes/kubernetes repository, you will come across a directory called staging/. The sub-folders in this directory serve as a bunch of pseudo-repositories. For example, the kubernetes/client-go repository that publishes releases for client-go is actually a staging repo. FSM: So the concept of staging directories fundamentally impact contributions? MJ: Precisely, because if you’d like to contribute to any of the staging repos, you will need to send in a PR to its corresponding staging directory in kubernetes/kubernetes. Once the code merges there, we have a bot called the publishing-bot that will sync the merged commits to the required staging repositories (like kubernetes/client-go). This way we get the benefits of a monorepo but we also can modularly publish code for downstream consumption. PS: The publishing-bot needs more folks to help out! For more information on staging repositories, please see the contributor documentation. FSM: Speaking of contributions, the very high number of contributors, both individuals and companies, must also be a challenge: how does the subproject operate in terms of making sure that standards are being followed? MJ: When it comes to dependency management in the project, there is a dedicated team that helps review and approve dependency changes. These are folks who have helped lay the foundation of much of the tooling that Kubernetes uses today for dependency management. This tooling helps ensure there is a consistent way that contributors can make changes to dependencies. The project has also worked on additional tooling to signal statistics of dependencies that is being added or removed: depstat Apart from dependency management, another crucial task that the project does is management of the staging repositories. The tooling for achieving this (publishing-bot) is completely transparent to contributors and helps ensure that the staging repos get a consistent view of contributions that are submitted to kubernetes/kubernetes. Code Organization also works towards making sure that Kubernetes stays on supported versions of Go. The linked KEP provides more context on why we need to do this. We collaborate with SIG Release to ensure that we are testing Kubernetes as rigorously and as early as we can on Go releases and working on changes that break our CI as a part of this. An example of how we track this process can be found here. Release cycle and current priorities FSM: Is there anything that changes during the release cycle? MJ During the release cycle, specifically before code freeze, there are often changes that go in that add/update/delete dependencies, fix code that needs fixing as part of our effort to stay on supported versions of Go. Furthermore, some of these changes are also candidates for backporting to our supported release branches. FSM: Is there any major project or theme the subproject is working on right now that you would like to highlight? MJ: I think one very interesting and immensely useful change that has been recently added (and I take the opportunity to specifically highlight the work of Tim Hockin on this) is the introduction of Go workspaces to the Kubernetes repo. A lot of our current tooling for dependency management and code publishing, as well as the experience of editing code in the Kubernetes repo, can be significantly improved by this change. Wrapping up FSM: How would someone interested in the topic start helping the subproject? MJ: The first step, as is the first step with any project in Kubernetes, is to join our slack: slack. K8s. Io, and after that join the #k8s-code-organization channel. There is also a code-organization office hours that takes place that you can choose to attend. Timezones are hard, so feel free to also look at the recordings or meeting notes and follow up on slack! FSM: Excellent, thank you! Any final comments you would like to share? MJ: The Code Organization subproject always needs help! Especially areas like the publishing bot, so don’t hesitate to get involved in the #k8s-code-organization Slack channel.

Spotlight on SIG Architecture: Code Organization

Unlock DevOps Insights & AI Success Secrets!

In this edition of CloudOps Weekly, explore the latest trends and critical updates in the DevOps and cloud technology space. Aembit's 2024 survey report sheds light on significant security vulnerabilities associated with non-human identities, emphasizing the urgency for enhanced DevSecOps practices. Dive into Docker best practices and optimal strategies for managing container ecosystems to boost efficiency and reduce overhead. Learn about the transformative impact of AI in ServiceOps, the critical role of GPU data orchestration in AI workflows, and why IT's next challenges extend beyond cloud adoption. Stay informed with AWS's latest announcements and new HIPAA-eligible services. Additionally, celebrate INE Security's achievement for winning the 2024 SC Excellence Award, and gain insights from the Kubernetes SIG Architecture's latest enhancements. These articles collectively keep you updated and positioned at the forefront of the industry.

CloudOps Weekly highlights Aembit's 2024 survey on non-human identity security gaps, Docker management techniques, AI's role in ServiceOps, and AWS's latest updates. Celebrate INE Security's SC Excellence Award win and explore Kubernetes SIG Architecture advancements.

The article reveals findings from the Verizon Data Breach Investigations Report indicating a rise in ransomware attacks targeted at small and medium-sized businesses (SMBs). The analysis highlights the increased vulnerability of SMBs due to their often limited cybersecurity resources. Additionally, the report outlines proactive measures SMBs can adopt to mitigate risk and protect their operations from cyber threats.

While the Verizon annual report showed that ransomware is rising, it also found that ransom payments are in decline

Verizon DBIR: Small Businesses Bearing the Brunt of Ransomware Attacks

CloudOps Weekly: EC2 Innovations & Security Alerts!

In this issue of CloudOps Weekly, we explore significant updates and analyze critical developments in the realm of cloud technology and DevOps. Notably, the RedMonk data unveils that shifts from open source to proprietary licenses have shown minimal impact on community adoption, showcasing the resilience of open source software. Amazon introduces its latest EC2 C8g and M8g instances, powered by Arm-based AWS Graviton3 processors, offering improved sustainability and performance for compute-intensive tasks. Yet another highlight is the revelation of a critical flaw in Commvault's Command Center, urging users to update and securitize their systems to prevent remote code execution attacks.

Web components through Lit and Shoelace are scrutinized for their pros and cons, aiding developers in modern web development. Meanwhile, the Verizon DBIR report flags the growing threat of ransomware on small businesses and recommends measures for risk mitigation. On the cutting edge of cloud infrastructure, advancements like the memory-optimized Graviton4-powered EC2 X8g instances and F5's enhanced capabilities in the NGINX platform highlight strategic improvements.

Additionally, this newsletter delves into autonomous observability and how AI and ML are revamping system monitoring. Lastly, the focus on automating Kubernetes cluster security emphasizes the ongoing efforts to weave robust security practices within cloud orchestration. These insights are designed to keep readers informed and empowered as they navigate the dynamic landscape of cloud technology.

This week in CloudOps: RedMonk shows open source resilience amid licensing changes. Amazon debuts sustainable EC2 C8g & M8g instances with Graviton3. Commvault flaw urges immediate updates for security. Explore web components with Lit & Shoelace. F5 enhances NGINX cloud solutions. The Verizon report warns SMBs of rising ransomware risk. Dive into autonomous observability and Kubernetes security automation.

The article explores how 27Global aids companies in their digital transformation by leveraging cloud services to enhance operational efficiency and boost innovation. It highlights the company's customer-centric approach in implementing cloud-based solutions tailored to meet specific business needs, ensuring scalability and flexibility. Additionally, the article discusses the importance of strategic cloud adoption in maintaining competitive advantage in today's rapidly evolving technological landscape.

Almost overnight, moving to the cloud has become an absolute necessity for ensuring a company s business continuity and long-term existence. To avoid unnecessary challenges, organizations need an experienced cloud partner to deliver a tailored and optimal solution.

27Global Cloud Transformation

Uncover DevOps Secrets & Bust Docker Myths!

In this week's CloudOps Weekly, delve into essential security practices with an exploration of secret remediation best practices, crucial for DevSecOps professionals aiming to fortify their environments. Discover strategies for managing complex codebases in 'Buried in Code', enhancing collaboration and maintainability within DevOps teams. Understand the pivotal role of secure API development as we uncover common API vulnerabilities and the importance of addressing them to protect sensitive data. Learn how 27Global facilitates digital transformation through cloud services, enhancing operational efficiency and innovation, and offering a complimentary IT assessment to optimize DevOps practices and IT infrastructure. Further, explore the balance of cloud cost optimization with engineering efficiency, and debunk popular myths about Docker to refine your understanding of container technology. Stay informed about the sophisticated cyber threats posed by the Lazarus hacking group targeting South Korean firms, and leverage the CNCF Artifact Hub for a streamlined approach to managing cloud-native artifacts.

This week in CloudOps: Secure your software with secret remediation strategies, manage complex codebases effectively, and learn about API vulnerabilities. Explore cloud transformation with 27Global and enhance DevOps with their free assessment. Optimize cloud costs, debunk Docker myths, and stay vigilant against sophisticated cyber threats. Discover CNCF Artifact Hub for streamlined cloud-native solutions.

Docker has announced the updates to their plans coming in November 2024, focusing on enhancing containerization capabilities and user experience. These changes aim to offer more flexibility and improved features to help developers manage their containerized applications more effectively. These updates reflect Docker's commitment to supporting developers with robust solutions that enhance productivity and streamline workflows.

Docker announces significant upgrades to its subscription plans, delivering more value, flexibility, and tools for customers of all sizes.

Announcing Upgraded Docker Plans: Simpler, More Value, Better Development and Productivity

"Stay Ahead: DevOps Trends & Outage Solutions"

This edition of CloudOps Weekly brings you valuable insights across several key areas in the DevOps and cloud landscape. Key highlights include an article on best practices for managing major outages, which emphasizes preparation, communication, and collaboration for successful recovery. A survey by Vanson Bourne reveals an uptick in DevOps adoption within mainframe environments, underscoring a shift towards modernizing legacy systems. Additionally, we explore the integration of Quality Assurance with platform engineering to optimize CI/CD processes. Exciting updates from Docker promise enhanced containerization capabilities, with simpler plans and improved features coming in November 2024, and new enterprise admin features for Desktop with MSI installer and login options. A case study on John Deere illustrates running AI models without GPUs by leveraging cloud capabilities, while a survey highlights how compensation influences open source security behaviors. Learn about the new Kubernetes v1.31 release, offering enhanced security and scalability, and discover how Testcontainers is improving integration testing for Mattermost plugins by providing reliable and predictable test environments.

In this issue: Best outage management practices, mainframe DevOps growth, QA & platform engineering synergy, new Docker upgrades, running AI without GPUs, and Kubernetes v1.31 insights. Plus, compensation's impact on open source security and Testcontainers for Mattermost plugins.

The article explores the introduction of recursive read-only mounts in Kubernetes, detailing the enhancement's utility in improving security and data integrity in containers. It explains how this feature allows for more granular control over filesystem permissions, effectively limiting write access and reducing attack surfaces. The implementation specifics and potential benefits for Kubernetes users aiming to adopt more secure container practices are also discussed.

Read-only volume mounts have been a feature of Kubernetes since the beginning. Surprisingly, read-only mounts are not completely read-only under certain conditions on Linux. As of the v1. 30 release, they can be made completely read-only, with alpha support for recursive read-only mounts. Read-only volume mounts are not really read-only by default Volume mounts can be deceptively complicated. You might expect that the following manifest makes everything under /mnt in the containers read-only: --- apiVersion: v1 kind: Pod spec: volumes: - name: mnt hostPath: path: /mnt containers: - volumeMounts: - name: mnt mountPath: /mnt readOnly: true However, any sub-mounts beneath /mnt may still be writable! For example, consider that /mnt/my-nfs-server is writeable on the host. Inside the container, writes to /mnt/* will be rejected but /mnt/my-nfs-server/* will still be writeable. New mount option: recursiveReadOnly Kubernetes 1. 30 added a new mount option recursiveReadOnly so as to make submounts recursively read-only. The option can be enabled as follows: --- apiVersion: v1 kind: Pod spec: volumes: - name: mnt hostPath: path: /mnt containers: - volumeMounts: - name: mnt mountPath: /mnt readOnly: true # NEW # Possible values are `Enabled`, `IfPossible`, and `Disabled`. # Needs to be specified in conjunction with `readOnly: true`. RecursiveReadOnly: Enabled This is implemented by applying the MOUNT_ATTR_RDONLY attribute with the AT_RECURSIVE flag using mount_setattr(2) added in Linux kernel v5. 12. For backwards compatibility, the recursiveReadOnly field is not a replacement for readOnly, but is used in conjunction with it. To get a properly recursive read-only mount, you must set both fields. Feature availability To enable recursiveReadOnly mounts, the following components have to be used: Kubernetes: v1. 30 or later, with the RecursiveReadOnlyMounts feature gate enabled. As of v1. 30, the gate is marked as alpha. CRI runtime: containerd: v2. 0 or later OCI runtime: runc: v1. 1 or later crun: v1. 8. 6 or later Linux kernel: v5. 12 or later What ' s next? Kubernetes SIG Node hope - and expect - that the feature will be promoted to beta and eventually general availability (GA) in future releases of Kubernetes, so that users no longer need to enable the feature gate manually. The default value of recursiveReadOnly will still remain Disabled, for backwards compatibility. How can I learn more? Please check out the documentation for the further details of recursiveReadOnly mounts. How to get involved? This feature is driven by the SIG Node community. Please join us to connect with the community and share your ideas and feedback around the above feature and beyond. We look forward to hearing from you!

Kubernetes 1.30: Read-only volume mounts can be finally literally read-only

CloudOps Weekly: AI Advances & DevOps Insights

Stay ahead in the world of DevOps and cloud technology with the latest issue of CloudOps Weekly. Explore how generative AI is transforming debugging in software development with its efficiency-enhancing and time-reducing capabilities. Learn about HashiCorp's exciting collaboration with AWS discussed at re:Invent 2024, where innovative DevSecOps practices are revolutionizing security lifecycle management in AWS environments. Dive into the challenges of AI-generated spam in open-source repositories and discover the importance of improved moderation to maintain development integrity. New Relic's unique take on AI observability in monitoring AWS Lambda response streaming is highlighted, offering insights into enhancing serverless application performance. Discover the performance upgrades in Python 3.13 and the enhanced security and data integrity offered by the latest Kubernetes 1.30 update. Explore strategic management of API consumption to optimize performance and security, and understand the benefits of integrating storage and databases under Kubernetes control. Finally, uncover best practices in API testing to bolster the security and reliability of your services.

Discover how AI is changing debugging, HashiCorp's security advancements with AWS, and the challenge of AI spam in open-source repositories. Learn about New Relic's AI observability, Python 3.13's performance boost, and Kubernetes updates. Explore API management strategies and testing practices.

This article is the third installment in a series focused on setting up a personal cloud using Kubernetes. It provides detailed guidance on configuring Kubernetes clusters and deploying applications, offering a hands-on approach for developers and IT professionals. Readers will gain practical insights into efficient resource management and scaling strategies for their cloud environments.

Approaching the most interesting phase, this article delves into running Kubernetes within Kubernetes. Technologies such as Kamaji and Cluster API are highlighted, along with their integration with KubeVirt. Previous discussions have covered preparing Kubernetes on bare metal and how to turn Kubernetes into virtual machines management system. This article concludes the series by explaining how, using all of the above, you can build a full-fledged managed Kubernetes and run virtual Kubernetes clusters with just a click. First up, let ' s dive into the Cluster API. Cluster API Cluster API is an extension for Kubernetes that allows the management of Kubernetes clusters as custom resources within another Kubernetes cluster. The main goal of the Cluster API is to provide a unified interface for describing the basic entities of a Kubernetes cluster and managing their lifecycle. This enables the automation of processes for creating, updating, and deleting clusters, simplifying scaling, and infrastructure management. Within the context of Cluster API, there are two terms: management cluster and tenant clusters. Management cluster is a Kubernetes cluster used to deploy and manage other clusters. This cluster contains all the necessary Cluster API components and is responsible for describing, creating, and updating tenant clusters. It is often used just for this purpose. Tenant clusters are the user clusters or clusters deployed using the Cluster API. They are created by describing the relevant resources in the management cluster. They are then used for deploying applications and services by end-users. It ' s important to understand that physically, tenant clusters do not necessarily have to run on the same infrastructure with the management cluster; more often, they are running elsewhere. A diagram showing interaction of management Kubernetes cluster and tenant Kubernetes clusters using Cluster API For its operation, Cluster API utilizes the concept of providers which are separate controllers responsible for specific components of the cluster being created. Within Cluster API, there are several types of providers. The major ones are: Infrastructure Provider, which is responsible for providing the computing infrastructure, such as virtual machines or physical servers. Control Plane Provider, which provides the Kubernetes control plane, namely the components kube-apiserver, kube-scheduler, and kube-controller-manager. Bootstrap Provider, which is used for generating cloud-init configuration for the virtual machines and servers being created. To get started, you will need to install the Cluster API itself and one provider of each type. You can find a complete list of supported providers in the project ' s documentation. For installation, you can use the clusterctl utility, or Cluster API Operator as the more declarative method. Choosing providers Infrastructure provider To run Kubernetes clusters using KubeVirt, the KubeVirt Infrastructure Provider must be installed. It enables the deployment of virtual machines for worker nodes in the same management cluster, where the Cluster API operates. Control plane provider The Kamaji project offers a ready solution for running the Kubernetes control plane for tenant clusters as containers within the management cluster. This approach has several significant advantages: Cost-effectiveness: Running the control plane in containers avoids the use of separate control plane nodes for each cluster, thereby significantly reducing infrastructure costs. Stability: Simplifying architecture by eliminating complex multi-layered deployment schemes. Instead of sequentially launching a virtual machine and then installing etcd and Kubernetes components inside it, there ' s a simple control plane that is deployed and run as a regular application inside Kubernetes and managed by an operator. Security: The cluster ' s control plane is hidden from the end user, reducing the possibility of its components being compromised, and also eliminates user access to the cluster ' s certificate store. This approach to organizing a control plane invisible to the user is often used by cloud providers. Bootstrap provider Kubeadm as the Bootstrap Provider - as the standard method for preparing clusters in Cluster API. This provider is developed as part of the Cluster API itself. It requires only a prepared system image with kubelet and kubeadm installed and allows generating configs in the cloud-init and ignition formats. It ' s worth noting that Talos Linux also supports provisioning via the Cluster API and has providers for this. Although previous articles discussed using Talos Linux to set up a management cluster on bare-metal nodes, to provision tenant clusters the Kamaji+Kubeadm approach has more advantages. It facilitates the deployment of Kubernetes control planes in containers, thus removing the need for separate virtual machines for control plane instances. This simplifies the management and reduces costs. How it works The primary object in Cluster API is the Cluster resource, which acts as the parent for all the others. Typically, this resource references two others: a resource describing the control plane and a resource describing the infrastructure, each managed by a separate provider. Unlike the Cluster, these two resources are not standardized, and their kind depends on the specific provider you are using: A diagram showing the relationship of a Cluster resource and the resources it links to in Cluster API Within Cluster API, there is also a resource named MachineDeployment, which describes a group of nodes, whether they are physical servers or virtual machines. This resource functions similarly to standard Kubernetes resources such as Deployment, ReplicaSet, and Pod, providing a mechanism for the declarative description of a group of nodes and automatic scaling. In other words, the MachineDeployment resource allows you to declaratively describe nodes for your cluster, automating their creation, deletion, and updating according to specified parameters and the requested number of replicas. A diagram showing the relationship of a MachineDeployment resource and its children in Cluster API To create machines, MachineDeployment refers to a template for generating the machine itself and a template for generating its cloud-init config: A diagram showing the relationship of a MachineDeployment resource and the resources it links to in Cluster API To deploy a new Kubernetes cluster using Cluster API, you will need to prepare the following set of resources: A general Cluster resource A KamajiControlPlane resource, responsible for the control plane operated by Kamaji A KubevirtCluster resource, describing the cluster configuration in KubeVirt A KubevirtMachineTemplate resource, responsible for the virtual machine template A KubeadmConfigTemplate resource, responsible for generating tokens and cloud-init At least one MachineDeployment to create some workers Polishing the cluster In most cases, this is sufficient, but depending on the providers used, you may need other resources as well. You can find examples of the resources created for each type of provider in the Kamaji project documentation. At this stage, you already have a ready tenant Kubernetes cluster, but so far, it contains nothing but API workers and a few core plugins that are standardly included in the installation of any Kubernetes cluster: kube-proxy and CoreDNS. For full integration, you will need to install several more components: To install additional components, you can use a separate Cluster API Add-on Provider for Helm, or the same FluxCD discussed in previous articles. When creating resources in FluxCD, it ' s possible to specify the target cluster by referring to the kubeconfig generated by Cluster API. Then, the installation will be performed directly into it. Thus, FluxCD becomes a universal tool for managing resources both in the management cluster and in the user tenant clusters. A diagram showing the interaction scheme of fluxcd, which can install components in both management and tenant Kubernetes clusters What components are being discussed here? Generally, the set includes the following: CNI Plugin To ensure communication between pods in a tenant Kubernetes cluster, it ' s necessary to deploy a CNI plugin. This plugin creates a virtual network that allows pods to interact with each other and is traditionally deployed as a Daemonset on the cluster ' s worker nodes. You can choose and install any CNI plugin that you find suitable. A diagram showing a CNI plugin installed inside the tenant Kubernetes cluster on a scheme of nested Kubernetes clusters Cloud Controller Manager The main task of the Cloud Controller Manager (CCM) is to integrate Kubernetes with the cloud infrastructure provider ' s environment (in your case, it is the management Kubernetes cluster in which all worksers of tenant Kubernetes are provisioned). Here are some tasks it performs: When a service of type LoadBalancer is created, the CCM initiates the process of creating a cloud load balancer, which directs traffic to your Kubernetes cluster. If a node is removed from the cloud infrastructure, the CCM ensures its removal from your cluster as well, maintaining the cluster ' s current state. When using the CCM, nodes are added to the cluster with a special taint, node. Cloudprovider. Kubernetes. Io/uninitialized, which allows for the processing of additional business logic if necessary. After successful initialization, this taint is removed from the node. Depending on the cloud provider, the CCM can operate both inside and outside the tenant cluster. The KubeVirt Cloud Provider is designed to be installed in the external parent management cluster. Thus, creating services of type LoadBalancer in the tenant cluster initiates the creation of LoadBalancer services in the parent cluster, which direct traffic into the tenant cluster. A diagram showing a Cloud Controller Manager installed outside of a tenant Kubernetes cluster on a scheme of nested Kubernetes clusters and the mapping of services it manages from the parent to the child Kubernetes cluster CSI Driver The Container Storage Interface (CSI) is divided into two main parts for interacting with storage in Kubernetes: csi-controller: This component is responsible for interacting with the cloud provider ' s API to create, delete, attach, detach, and resize volumes. Csi-node: This component runs on each node and facilitates the mounting of volumes to pods as requested by kubelet. In the context of using the KubeVirt CSI Driver, a unique opportunity arises. Since virtual machines in KubeVirt runs within the management Kubernetes cluster, where a full-fledged Kubernetes API is available, this opens the path for running the csi-controller outside of the user ' s tenant cluster. This approach is popular in the KubeVirt community and offers several key advantages: Security: This method hides the internal cloud API from the end-user, providing access to resources exclusively through the Kubernetes interface. Thus, it reduces the risk of direct access to the management cluster from user clusters. Simplicity and Convenience: Users don ' t need to manage additional controllers in their clusters, simplifying the architecture and reducing the management burden. However, the CSI-node must necessarily run inside the tenant cluster, as it directly interacts with kubelet on each node. This component is responsible for the mounting and unmounting of volumes into pods, requiring close integration with processes occurring directly on the cluster nodes. The KubeVirt CSI Driver acts as a proxy for ordering volumes. When a PVC is created inside the tenant cluster, a PVC is created in the management cluster, and then the created PV is connected to the virtual machine. A diagram showing a CSI plugin components installed on both inside and outside of a tenant Kubernetes cluster on a scheme of nested Kubernetes clusters and the mapping of persistent volumes it manages from the parent to the child Kubernetes cluster Cluster Autoscaler The Cluster Autoscaler is a versatile component that can work with various cloud APIs, and its integration with Cluster-API is just one of the available functions. For proper configuration, it requires access to two clusters: the tenant cluster, to track pods and determine the need for adding new nodes, and the managing Kubernetes cluster (management kubernetes cluster), where it interacts with the MachineDeployment resource and adjusts the number of replicas. Although Cluster Autoscaler usually runs inside the tenant Kubernetes cluster, in this situation, it is suggested to install it outside for the same reasons described before. This approach is simpler to maintain and more secure as it prevents users of tenant clusters from accessing the management API of the management cluster. A diagram showing a Cluster Autoscaler installed outside of a tenant Kubernetes cluster on a scheme of nested Kubernetes clusters Konnectivity There ' s another additional component I ' d like to mention - Konnectivity. You will likely need it later on to get webhooks and the API aggregation layer working in your tenant Kubernetes cluster. This topic is covered in detail in one of my previous article. Unlike the components presented above, Kamaji allows you to easily enable Konnectivity and manage it as one of the core components of your tenant cluster, alongside kube-proxy and CoreDNS. Conclusion Now you have a fully functional Kubernetes cluster with the capability for dynamic scaling, automatic provisioning of volumes, and load balancers. Going forward, you might consider metrics and logs collection from your tenant clusters, but that goes beyond the scope of this article. Of course, all the components necessary for deploying a Kubernetes cluster can be packaged into a single Helm chart and deployed as a unified application. This is precisely how we organize the deployment of managed Kubernetes clusters with the click of a button on our open PaaS platform, Cozystack, where you can try all the technologies described in the article for free.

DIY: Create Your Own Cloud with Kubernetes (Part 3)

"Drive AI & Cloud Innovations: Dive In Now!"

This week's CloudOps Weekly newsletter brings a wealth of insights and opportunities in the ever-evolving realm of DevOps and cloud technology. A key highlight is the article on empowering developers to drive AI innovation, emphasizing strategic alignment and resource allocation to unlock AI's potential. We also feature five exciting DevOps job openings across various industries, reflecting the growing demand for skilled professionals. Dive into the world of AI development with our behind-the-scenes look at GenAI's role in software solutions, revealing the challenges and processes developers face. Microsoft's ongoing efforts to innovate datacenter infrastructure and security are also spotlighted, showcasing advancements in energy efficiency and scalability. Additionally, Apica's new feature for centralizing telemetry data management promises to streamline DevOps environments. For those keen on cloud solutions, the third part of our Kubernetes series offers practical steps to set up your personal cloud. Budget-conscious readers will find value in our guide on cost-effective shift-left testing for microservices. ECMAScript's latest enhancements, including a new approval stage, bring exciting news for JavaScript developers, while the launch of VECTR Enterprise Edition by Security Risk Advisors promises to boost cybersecurity measures significantly. Stay informed and positioned at the forefront of industry advancements by subscribing to our newsletter.

CloudOps Weekly: Empower developers to boost AI innovation, explore top DevOps jobs, and learn about Microsoft’s advancements in datacenter security. Discover new features in telemetry management, cost-effective microservices testing, and stay updated on JavaScript’s ECMAScript enhancements and cybersecurity tools.

This article provides a comprehensive guide on setting up a Git local repository accessible over a local area network (LAN). It covers essential steps to facilitate collaboration through LAN access, detailing the configuration process for efficient team usage. The piece is ideal for DevOps professionals looking to enhance their team’s workflow with LAN-based version control systems.

A Git repository simplifies the sharing of code to a team. Many teams opt to go the GitHub route but The post Git: Set Up a Local Repository Accessible by LAN appeared first on The New Stack.

Git: Set Up a Local Repository Accessible by LAN

"Stay Ahead: CloudOps Trends & AI DevSecOps"

This week's issue of CloudOps Weekly covers essential topics in DevOps and cloud technology. Discover strategies to accelerate AI adoption for developers with actionable steps to integrate AI successfully and enhance project outcomes. Explore the launch of the Social Web Foundation aimed at promoting interoperability and inclusivity within the Fediverse, showcasing efforts from W3C to foster a more user-friendly social internet. Analyze the pros and cons of using Kubernetes for database management, focusing on scalability and automation versus implementation complexities. The integration of DevOps into edge computing is discussed, highlighting the need for quicker, reliable frameworks to improve user application performance. Learn about AI's potential in automating DevSecOps governance and enhancing security. A guide on setting up a Git repository over LAN can enhance team collaboration, while another article explores aligning life-long ambitions with DevOps culture for continuous improvement. Additionally, integrating threat modeling into DevOps security is shown to transform traditional pentesting. Finally, the AWS Weekly Roundup shares updates on G6e instances, Karpenter improvements, the significance of Amazon's Prime Day metrics, and AWS Certifications updates.

This week in CloudOps: AI adoption for developers, Social Web Foundation's launch to boost Fediverse, and Kubernetes pros/cons for databases. DevOps at the edge and AI's role in DevSecOps governance also featured. Check AWS updates on G6e instances and more!

Explore critical considerations when selecting a Cloud Native Application Protection Platform, emphasizing security integration, scalability, and compliance. Gain insights into evaluating product functionalities and vendor compatibility for streamlined DevSecOps processes. Ensure robust cloud-native environments by prioritizing features that align with organizational needs and future-proofing strategies.

Harsh truth: 90% of businesses take the wrong route to choose a cloud native application protection platform (CNAPP) vendor. Most The post Cloud Native App Protection Platforms: 6 Tips Before Buying appeared first on The New Stack.

Cloud Native App Protection Platforms: 6 Tips Before Buying

"Unlock CloudOps Insights: AI, Security & More!"

This week's edition of CloudOps Weekly delves into several crucial topics within the DevOps and cloud technology sphere. It opens with an in-depth article on graph embeddings, offering insights into their role in AI applications and how they can be used to uncover complex data relationships. In a spotlight on cybersecurity, the newsletter emphasizes the importance of gender diversity and the unique perspectives women bring to enhance security innovations. For developers, an article highlights Buildkite's expanded continuous delivery platform, designed to optimize large-scale software deployments. Additionally, this edition explores strategies for securing Docker Business and microservices in multicloud environments, ensuring robust security and compliance. The newsletter also features findings on the widespread adoption of generative AI among software engineers, indicating a significant shift in development practices. Lastly, INE's recognition as a leader by G2 for 2024 is celebrated, and the collaboration between the Internet Architecture Board and ISO for future networking tech is discussed.

CloudOps Weekly explores graph embeddings in AI, gender diversity in cybersecurity, and Buildkite's platform expansion. Dive into strategies for Docker Business security and multicloud protection. Generative AI adoption among developers takes center stage. INE excels as G2's 2024 leader, and future internet advancements are underway with IAB and ISO.

I'm curating this article for a newsletter, give me a 3 sentence summary of this article so I can copy and paste it in my newsletter.  Make the tone professional and concise.

Stay informed about the latest advancements in DevOps and cloud technology by subscribing to our weekly newsletter. 
Each edition provides curated insights and trends designed to keep you updated and positioned at the forefront of the industry.
Don't miss the opportunity to enhance your knowledge and stay ahead of the curve.