Welcome to Ignite 2020 the online edition. Though we are all connecting through computers, tablets and phones instead of in person, I’m excited to get the chance to meet our Azure customers, learn about how they are using Kubernetes on Azure and share the latest news about how we’re continuing to evolve the service to meet the needs of all operators, developers from hobbyists and startups, small businesses and of course the large enterprises. In my blog last month I talked about how the Azure Kubernetes Service (AKS) makes it easier to build and scale applications on Azure while still maintaining efficiency and reliability. From that foundation I’m excited to share even more features that help all of our users build and secure their applications on the Azure Kubernetes Service (AKS).
Though many customers use AKS to build reliable services that are available worldwide, 24/7, there are lots of other use cases, from batch workloads, dev/test and more, where the load is much more intermittent and at times, a cluster, or part of a cluster may be completely inactive. For a while now, AKS has supported rightsizing so that, for example, a user could scale their node-pool of GPU machines used for AI to zero when there are no machine learning jobs to process. This flexibility enables users to optimize the shape of their clusters to meet their needs more precisely.
Today, we are excited to announce new functionality that allows you to stop your cluster completely. A stopped cluster maintains all of the state in the cluster but eliminates any running resources that would otherwise be idle. Stopping a cluster adds even more flexibility to ensure that you can run Kubernetes the most efficiently on Azure.
Of course, rightsizing a cluster is only one part of ensuring that your workloads can run correctly. Another important part of the equation is ensuring that the cluster itself is operating properly. Last year we announced the development of the open source Periscope tool that provides deep introspection and debugging support for AKS clusters. This year we are making this tooling even easier to use by integrating it into Visual Studio Code and our Visual Studio extensions for Kubernetes. This integration means that installing Periscope and viewing its data can be done with a few clicks in your development environment.
Whether you are a startup or an enterprise, another important part of shaping a cluster to meet your needs is getting storage right. Different customers, and even different clusters for the same customer have different storage requirements. To meet this need you can now customize your default storage class in AKS and tune the storage requirements to suit the requirements of your applications.
One of the most important requirements of any business is security, especially for those workloads that are the crown jewels of your company. Azure has led the way with the development of confidential computing solutions that protect access to workloads, preventing even the Azure cloud provider from accessing the data in the secure enclaves on the VM. I’m thrilled to announce that we’re bringing this capability to Kubernetes so that your cloud-native workloads can run on confidential computing VMs. Our public preview of confidential computing nodes for AKS is a great addition. In addition to protecting at rest and in transit, confidential computing protects data-in-use by providing hardware-based assurances for data and code protection within containers. Confidential computing is enabling customer solutions for multi-party big data analytics, secrets & key management, blockchain privacy and confidential microservices in regulated industries of financial, health and government. This area is an exciting new area for cloud native computing and I’m looking forward to seeing Azure lead the way in securing our customer’s data and workloads.
Another important part of security is access control, and Azure Active Directory (AAD) is the best of breed solution for identity and access management that millions of people rely on every day. While we have had support for AAD identities in Kubernetes on Azure for a long time, at Ignite this year we are announcing support for Azure RBAC in the Azure Kubernetes Service. This means that you can use Azure’s RBAC to manage access to Kubernetes resources and centralize access control for both your Azure and Kubernetes resources in a single dashboard and set of role assignments. This also makes RBAC even easier to administer since the default roles (reader/writer/administrator) automatically work for Kubernetes resources in an Azure Kubernetes Service cluster. For many common use cases, RBAC will “just work” without any user interaction. We all know that the best security is the one that is on by default and I’m pleased that our integration with Azure RBAC will make Azure Kubernetes cluster even more secure.
RBAC is great for managing who can access a cluster and what resources they can access, but it’s not the full story for security. Azure Policy for Kubernetes can control the details of the resources that a user creates within a cluster, so that, for example, no one can accidentally expose a service on the public internet that allows malicious attackers to bitcoin mine on your cluster. Azure is an industry leader in cloud policy and donated the initial implementation of GateKeeper, the Kubernetes Policy controller to the Open Policy Agent and CNCF. It makes sense then that we are also the first cloud to make Kubernetes Policy generally available in our Azure Kubernetes Service. Policy is an integral part of securing Kubernetes, and now our enterprise customers can rely on the service guarantees that come with a generally available service.
One of the favorite parts of my job is connecting with our customers and learning about how they are using Kubernetes to transform their enterprises. One consistent theme in all of these conversations is the need for a Microsoft supported Kubernetes cluster anywhere their workload takes them. While many times this is in Azure, often times it is also in an on-premises environment. To meet these needs we’re announcing the public preview of AKS in Azure Stack Hub. AKS in Azure Stack Hub provides API level fidelity with the AKS experience in Azure so that you can create, delete and manage Kubernetes clusters with the same tools in both public cloud and air-gapped environments. If Azure Stack Hub doesn’t meet your needs, we are also announcing the availability of AKS on Azure Stack HCI. AKS on Azure Stack HCI enables a seamless, supported Kubernetes experience so that you can have the confidence that the applications you build for the public cloud and AKS can run smoothly on an Azure Stack HCI devices as well. With these new options, Kubernetes on Azure can meet your needs for cloud-native computing no matter where that computing needs to run.
Another common request from our users is access to the latest and greatest that Kubernetes has to offer. We’re thrilled to be the first cloud to make Kubernetes 1.18 available to mainstream users in their managed service, as well as the first cloud to make Kubernetes 1.19 available in preview. Bringing new versions of Kubernetes into our service requires strong integration with the upstream Kubernetes community and I want to thank our open source upstream team as well as the entire Azure Kubernetes team on all of the work needed to make the newest bits of Kubernetes available to our users so quickly.
I hope you have an amazing Ignite and you learn about more ways that Azure can help you transform your business. Every company’s digital transformation is different, but I’m confident that the Azure Kubernetes Service will continue to grow and expand to meet all of those needs!
Learn more about Kubernetes on Azure and get started with enterprise-grade Kubernetes today.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.