Announcing General Availability for GitOps with Flux v2 in Azure
This blog has been co-authored by Chris Sanders, Senior Program Manager, Azure Arc at Microsoft. GitOps capabilities have been an integral part of Azure Kubernetes Service (AKS) since its preview in December 2021 and Azure Arc-enabled Kubernetes since it’s launch at Ignite in 2021. Today, we are pleased to announce the General Availability of GitOps with Flux v2 in Azure Kubernetes Service (AKS) and Azure Arc-enabled Kubernetes (Arc K8s). With this release, Azure supports GitOps configuration and workload management for your entire cloud and hybrid Kubernetes estate – clusters in AKS and clusters on-premises or in other public clouds. Flux v2 is a major update bringing a Kubernetes-native architecture, observability, and multi-tenancy among other improvements. With a single tool and process, you can manage your modern applications in Kubernetes everywhere. Deploy modern applications in your cloud and hybrid environments Teams running modern, cloud-native applications need reliable, automated processes for managing Kubernetes cluster configuration and application lifecycle. GitOps is a technique for implementing continuous deployment for these applications and configurations and focuses on using tools and processes developers and cluster admins are familiar with, like Git and pull requests. GitOps enables infrastructure as code, where the state of the environment is declaratively described in Git repositories. Changes to the workload environment, such as an application update, happen via pull request to the Git repository, after which Flux, running in each cluster, automatically syncs the changes and applies them to the cluster. Flux also continuously assures that the cluster remains in the declared state. GitOps enables accurate change management and audit, as cluster state and all changes are fully visible in the Git repository. It also enhances cluster security, as developers and deployment tools don’t need direct access to clusters. In short, GitOps is the modern way to manage continuous deployment for your containerized workloads, and Azure GitOps with Flux brings this capability to you. How does this work? Azure uses open source CNCF Flux to enable GitOps in Azure Kubernetes Service (AKS) or Azure Arc-enabled Kubernetes (Arc K8s) clusters. Azure provides simple install, automatic update, and health reporting to simplify your use of GitOps across one to thousands of clusters. In Azure, GitOps with Flux v2 is enabled as a cluster extension to your AKS or Arc K8s clusters. The Flux extension installs the Flux controllers in the clusters. After Flux is enabled, you can then create one or more GitOps configurations in each cluster which enable the connections to your Git repositories and the deployment of the resources defined in the repositories. Importantly, in Azure you can track the compliance state of the deployments in each cluster to assure that the clusters are in the state you declared in your Git repositories. This gives you the observability you need to assure healthy cluster state. GitOps extension for VS Code We also are happy to announce the release of the new GitOps extension for VS Code. You can manage GitOps with Flux in your AKS, Arc-enabled Kubernetes, or other Kubernetes clusters directly within the VS Code client. This can simplify the developer inner loop when working with clusters managed by GitOps Flux. Some key features are: View list of configured clusters and switch cluster context AKS, Arc K8s, and other clusters are identified View Flux controllers, state, and logs View sources (Git and Helm Repositories, Bucket) and workloads (Kustomization, Helm Release) Create Git Repository source and Kustomization workload on the cluster Reconcile Sources and Workloads on demand Load Kubernetes Object manifest .yaml configs in VS Code editor Pull Git Repository Source to user machine and open it in VS Code Links to GitOps, Flux, and Azure Kubernetes documents This is an open-source project, and your contributions are welcome to improve the GitOps extension. Open-Source Partnerships The work to integrate Flux in Azure GitOps, enhance Flux capabilities, and create the VS Code extension has been done in partnership with Weaveworks and the Flux maintainers. Microsoft is continuing to partner with Weaveworks and participate in advancing the Flux CNCF project and OpenGitOps. Next Steps We are excited for you to start using the new capabilities in GitOps with Flux v2 in Azure Kubernetes Service and Azure Arc-enabled Kubernetes. For details on how you can get started, please see these documents: GitOps in Azure conceptual overview Tutorial: Use GitOps with Flux v2 in Azure Arc-enabled Kubernetes or AKS clusters Leverage the Azure Arc Jumpstart to get started quickly with an AKS cluster Azure Architecture Center GitOps for AKSGeneral Availability of the Dapr Extension
We are excited to announce General Availability of the Dapr extension for Arc-enabled Kubernetes clusters alongside AKS. Distributed Application Runtime (Dapr) is a set of incrementally adoptable APIs that ease the implementation of common cloud-native patterns found in microservice applications. By leveraging the benefits of a sidecar architecture, Dapr helps developers tackle the challenges of building microservices while keeping code platform-agnostic. Dapr APIs, also referred to as building blocks: Seamlessly fit with your preferred language or framework Allow you to use one, several, or all the building blocks, depending on your needs Are built on best practice industry standards For example, you can enable Dapr on your application to provide intercommunication through messaging via the Pub/Sub API, or reliable and secure service-to-service calls via the Service Invocation API. The below image depicts the various Dapr building blocks your microservices can leverage. The Dapr extension provisions Dapr on your Arc-enabled Kubernetes clusters, eliminating the overhead of downloading any Dapr tooling or manually installing and managing the Dapr runtime on your cluster. After writing Dapr into your application (in this example, using the Dapr .NET SDK to publish a message to a topic): using var client = new DaprClientBuilder().Build(); await client.PublishEventAsync("order_pub_sub", "orders", order); You can use the az k8s-extension CLI to install the Dapr control plane on your Arc-enabled Kubernetes clusters. The same Azure CLI commands are used to managed Dapr on AKS clusters. For AKS, swamp out the --cluster-type value of connectedClusters with managedClusters. Use the following command in the Azure CLI: az k8s-extension create --extension-type Microsoft.Dapr \ --cluster-type connectedClusters \ --cluster-name myCluster \ --resource-group myResourceGroup \ --name myDaprExtension The extension offers a fully supported version of Dapr and integrates with all native Dapr configuration capabilities through simple command-line arguments. For example, to provision Dapr with high availability (HA) enabled, set the global.ha.enabled parameter to ‘true’: --configuration-settings "global.ha.enabled=true" The extension platform provides the ability to set auto-upgrades for the Dapr control plane, making it easy for you to align to the latest minor version of Dapr. Specify the --auto-upgrade-minor-version parameter and setting the value to 'true': --auto-upgrade-minor-version true Once the extension is installed, the Dapr control plane is created on your Arc-enabled Kubernetes cluster. Your application code, instrumented with Dapr, can immediately begin leveraging the Dapr APIs. Try the Dapr extension sample on your Arc-enabled Kubernetes cluster. For more information, refer to the Dapr cluster extension documentation.Announcing ArcBox for DevOps
Since we released Jumpstart ArcBox 2.0 and the new ITPro flavor, the number of positive responses and customer adoption has been awesome. The new ArcBox modular design allows us to more rapidly iterate, and today we are excited to share a new offering: ArcBox for DevOps.GA: Azure Key Vault secrets provider extension for Arc enabled Kubernetes clusters
The Azure Arc team is happy to announce the GA of Azure Key Vault Secrets Provider extension for Arc enabled Kubernetes clusters. This is a Microsoft managed extension that allows you to get secret contents stored in an Azure Key Vault instance and mount them into Kubernetes pods of your Azure Arc enabled Kubernetes clusters, thereby reducing the exposure of secrets to the minimum. It can pull any type of object from an Azure Key Vault, including keys, secrets and certificates. The extension is installed by a cluster admin. With the installation, Secrets Store CSI driver and AKV secrets provider are deployed as daemon sets. On application pod start and restart, the Secrets Store CSI driver communicates with the Azure Key Vault secrets provider using gRPC to retrieve the secret content from the Azure Key Vault. Then the volume is mounted in the pod as tmpfs and the secret contents are written to the volume. On pod delete, the corresponding volume is cleaned up and deleted. This extension can be deployed using az k8s-extension CLI and also using Azure Portal. For deployment through portal, go to the Arc connected Kubernetes cluster and click on Extensions under Settings. Further, click on +Add to add Azure Key Vault Secrets Provider extension. Check out the full documentation on how to enable it for an Arc enabled Kubernetes cluster. The extension allows for 3 configuration options: Secret Rotation - Periodically update the pod mount with the latest secret from the AKV secrets store. The polling of latest secret does not require pod restart. It is disabled by default. Rotation Poll Interval - Frequency of the pod mount update if Secret Rotation configuration is enabled. The default is 2 minutes. Sync as Kubernetes secret - Create Kubernetes secret(s) to mirror the mounted content. It is disabled by default. A service principal is required to enable the access to Azure Key Vault from within the Arc cluster. Further, a Kubernetes secret needs to be created in the application namespace that references this service principal in order to gain access to the vault. What next? The identity option available today is service principal. However, we are investing in using workload identity as another option in future. Learn more at the Azure Hybrid, Multicloud, and Edge Day digital event We will be hosting our annual Azure Hybrid, Multicloud, and Edge Day digital event on June 15, 2022. You’ll hear from Microsoft leadership and engineers on how you can innovate anywhere with Azure Arc, learn from customers using Azure solutions for their hybrid scenarios, and get to ask questions in the live Q&A chat. Register now >Azure Arc-enabled SQL Managed Instance Business Critical now generally available!
Today we announced the General availability of Azure Arc-enabled SQL MI Business critical tier at the Microsoft Build 2022 conference. This is the second major release of Arc-enabled SQL MI and SQL Server on Arc-enabled server which will help SQL Server customers globally to achieve business continuity running their data workloads on the Azure Edge while connected to Azure. In this blog, we will do a tour of these new improvements and benefits of the Business critical tier and General purpose tier.
