Azure Container Apps Virtual Network Integration
Today, we are excited to announce that Azure Container Apps can be deployed into a custom Azure Virtual Network (VNet)! With the release of the Azure Container Apps BYO VNet capability, customers can now configure both inbound and outbound VNet integration for their Azure Container Apps environment.
Azure Kubernetes Service Baseline - The Hard Way
Are you ready to tackle Kubernetes on Azure like a pro? Embark on the “AKS Baseline - The Hard Way” and prepare for a journey that’s likely to be a mix of command line, detective work and revelations. This is a serious endeavour that will equip you with deep insights and substantial knowledge. As you navigate through the intricacies of Azure, you’ll not only face challenges but also accumulate a wealth of learning that will sharpen your skills and broaden your understanding of cloud infrastructure. Get set for an enriching experience that’s all about mastering the ins and outs of Azure Kubernetes Service!Getting started with GitOps, Argo, and Azure Kubernetes Service
First, what is GitOps? Is it the same as DevOps? I'm so glad you asked. Let's begin with a refresher on what DevOps is: "DevOps is the union of people, process, and products to enable the continuous delivery of value to our end users." ~ Donovan Brown Donovan puts it best - DevOps is a combination of several key factors: people, process, and products - but it starts with people. Getting started with DevOps involves a cultural shift, which means it's so much more than buzz words like agile, continuous integration, continuous deployment, automation, etc. While those buzz words have their place and are needed, truly embracing DevOps means creating a DevOps culture between your engineering teams - this includes developers, operations, security, and beyond.Azure Kubernetes upgrades and Long Term Support
Microsoft has long invested in the upstream Kubernetes community, and as our Azure team members have led and participated in the Kubernetes release process, we’ve listened to what our customers say about the pace of Kubernetes development. Today we are excited to announce the introduction of Azure Kubernetes Service (AKS) Long Term Support (LTS). We’re hearing from customers across a variety of organizations, from healthcare to manufacturing and beyond, who need a longer window of stability. We’ve heard from ISVs that having to be on a constant treadmill to keep their environments in sync with community releases adds a significant burden to delivering value to their customers. For organizations with multiple teams or complex environments, staying on top of upgrades can pose a significant challenge. With three releases happening each year and a year of support for any given release, updates require frequent action. LTS will help teams plan and test upgrades on a longer timeline, while staying on a supported Kubernetes version. It is critically important for all Kubernetes users that when they choose to run their applications on versions of Kubernetes that are not maintained by the community that the entire stack from the operating system to the Kubernetes components are maintained and patched by their service provider. The only way to host your applications on a Kubernetes version that is out of community support is to either run without security updates, or to put significant effort into forking the version, and cherry picking or resolving security issues yourself. Based on feedback from our customers, we decided to put a team together to do just that. We will be forking and maintaining the Kubernetes codebase for the LTS version once it leaves community support and maintaining this in the open. The first AKS version that can have Long Term Support will be 1.27, to be released in May 2023. While running a cluster at an LTS version, customers will receive support and security updates for two years from the GA date (instead of the usual one year). We intend to restart the community’s kubernetes WG-LTS to collaborate across the ecosystem to collect requirements and define processes and tooling required for creating secure and stable long term support releases of Kubernetes in the future. https://github.com/aks-lts is a work in progress, and we welcome feedback and contributions. Customers will be able to opt in to LTS support for Kubernetes 1.27 at any time, or spin up Kubernetes 1.27 clusters and node pools during that two year period. Making upgrades simple and safe Upgrading with confidence requires an understanding of how any change will affect your continuity of cluster operations. AKS supports fully automated in-place cluster upgrades (controlled via upgrade schedules) or manual in case you need more control over when these happen. In order to make the upgrade process for Kubernetes minor versions easier, the objects in ETCD are automatically converted to the newer APIs. And now AKS will detect if you are using a deprecated API anywhere (for example operators or your code), and we will prevent the upgrade, and warn you in order to stop you from inadvertently breaking your applications. You can override to force the upgrade or correct the API usage and retry after a period of time. You decide when to move from one Kubernetes version to another, allowing you to plan and test your migrations. For non-LTS clusters, each Kubernetes version is supported for 12 months. After 12 months, the minor version will shift to platform support only. Our new platform support policy provides customers with Azure infrastructure support while the cluster is in an n-3 version (where n is the latest supported AKS GA minor version). Platform support does not include anything related to Kubernetes functionality and components, but provides customers with additional support beyond what was previously provided for unsupported versions. AKS will make the automatic upgrade of out of support clusters predictable to ensure they remain within a Kubernetes supported version. When a cluster in an n-3 version is about to drop to n-4, AKS will automatically upgrade the cluster to n-2. For example, Kubernetes v1.25 will be upgraded to v1.26 during the v1.29 GA release. For more information, see the AKS documentation. We always recommend our customers stay within community support, and whether your needs are best served by an LTS Kubernetes release or an automatically upgraded cluster, Azure's support commitment to you is the same. Instead of a constant race to keep up with an ever-changing API surface while worrying about unpatched CVEs, Azure Kubernetes Service customers can grow their cloud native estates in confidence of their support and continuity. For more information on Kubernetes version support on AKS, assess your options, and for pricing information, take a look at the Supported Kubernetes section on Azure Docs.Azure Kubernetes Service Microsoft Ignite announcements
When we talk to Azure Kubernetes Service (AKS) customers about the adoption of Kubernetes, two focus areas come up just about every time: the challenges of running at scale and the ongoing desire to improve their security posture. At Microsoft Ignite 2022, we announced a number of new features for AKS to help you operate your Kubernetes clusters and workloads at the scale you need, and we’ve continued to innovate in the open to improve the security posture and landscape, providing a seamless, and secure platform for your applications.Preview support for Kata VM Isolated Containers on AKS for Pod Sandboxing
The rise of cloud-native and shift to containerized workloads has revolutionized the velocity of application development and drastically improved the ease of deployment when building applications. While these technologies provide many benefits, they also present a security risk when the shared kernel and the container host are exposed to untrusted malicious container code. One way to mitigate this risk is by running each pod/container in a dedicated, lightweight VM with resources like compute, memory, networking carved out from the parent VM on a dedicated kernel. This is known as Pod Sandboxing. Pod Sandboxing allows you to continue to co-locate pods on the same host but adds a layer of isolation to help mitigate shared kernel attacks and reduce risks from escaped containers when running in a shared agent node.
