4 min read

Empowering cloud-native developers on Kubernetes anywhere

Hello KubeCon and welcome to San Diego! It’s fantastic to have the chance to get some warm California sun, as well as the warmth of the broader Kubernetes community. From the very first community meeting, through the first KubeCon and on to today, it’s been truly amazing to have been able to watch and help the Kubernetes community grow. As KubeCon arrives, I’m excited to note how we are continuing to innovate and empower cloud-native developers on Kubernetes anywhere.

In the spirit of innovation, I’m thrilled to announce our new open source effort to enable trusted execution environments for Kubernetes. Trusted execution environments or “enclaves” are a hardware-backed secure execution environment that can ensure processes and their memory are secure while they execute. Today, we’re enabling trusted computing on Kubernetes anywhere via the Open Enclave SDK.

We’re also releasing a resource plugin that makes Encrypted Page Cache RAM a resource that the Kubernetes scheduler can use to make scheduling decisions. The number of enclaves on a CPU is limited, and this plugin ensures that Pods that need enclaves will be guaranteed to land on a node with an enclave available. This scheduler support is critical to running trusted compute environments in cloud-native applications via Pods.

Beyond these innovations for secure computing, I’m incredibly proud of the work that the Helm community has done to build and release Helm 3.0 last week. The vast majority of workloads deployed to Kubernetes are deployed via Helm, and Helm 3 is the next step in this journey. Over the past few years, the Helm team has carefully listened to user feedback about what was working and where changes were needed.

Of the many fixes and improvements, the most popular is probably the removal of Tiller from the cluster, making Charts more Kubernetes native and more secure by default. Speaking of security, the recent glowing independent security review of the Helm code base shows how dedicated and careful the Helm community has been in building a tool that is not just incredibly useful, but also secure as well. Many congratulations to the Helm community on this important milestone.

Just like the Helm team, in Azure, our open source work begins by listening to our customers. In particular, our customers in IoT and telecommunications. This feedback led us to understand how important it was for Kubernetes to support both IPv4 and IPv6 addresses for the same Pods in Kubernetes. Major kudos are due to Kal Henidak for his dedicated and tireless work in engineering both the code and design changes necessary to support multiple addresses per Pod. As you might imagine this change required careful work and coordination across the entire Kubernetes code base and community. Kal’s hard work in collaboration with the SIG-Networking community is being recognized with a shared keynote with Tim Hockin. Plan on attending the keynote to learn more about IPv4 and IPv6 in Kubernetes!

Finally, by combining both open source community and innovation we have a remarkable collection of open source projects reaching important milestones at KubeCon. The newly announced Buck (Brigade Universal Controller for Kubernetes) project shows how Cloud Native Application Bundles (CNAB) with Brigade radically simplify the development of new operators. The Kubernetes-based Event-driven Autoscaling (KEDA) has shown incredible community interest. It’s a great collaboration between Azure Functions, Red Hat, and others. Here at KubeCon, the KEDA community is hitting the 1.0 milestone and is stable and ready for production use. I also want to congratulate the Cloud Events community on their recent 1.0 release and I’m excited that Azure Event Grid has correspondingly added support for the 1.0 version of Cloud Events. Cloud Events is a CNCF project for an open and portable API for event-driven programming and it’s awesome that it is available in a managed environment in Azure.

Of course, containers and DevOps are a year-round focus for my teams beyond KubeCon. We’ve been busy this fall.

In the four weeks since we launched the Distributed Application Runtime (Dapr) project, we have seen strong interest from the community and have been listening to the many stories of how people are using Dapr in their projects, including modernizing Java code, building games, and integrating with IoT solutions. The breadth across different industries is amazing to see. The interest in the Dapr runtime repo has grown beyond our expectations. It’s been awesome to see the community come together and continue the momentum. We are excited to announce the release of Dapr v0.2.0, focusing on community-driven components, fixes across the Dapr runtime and CLI, updates to documentation, samples, and the addition of an end-to-end testing framework. You can find out more about the v0.2.0 release at the Dapr repo.

Just building distributed systems isn’t enough, you need to be able to observe how they are running in production, and the CNCF Prometheus project has emerged as a de-facto standard for exposing metrics on all sorts of servers. But it’s still easier to integrate with cloud-based monitoring rather than run your own metrics server. To enable this, Azure Monitor for containers can scrape the metrics exposed from Prometheus end-points so you can quickly gather failure rates, response per secs, and latency. From Log Analytics, you can easily run a Kusto Query Language (KQL) query and create your custom dashboard in the Azure portal dashboard. For many customers using Grafana to support their dashboard requirements, you can visualize the container and Prometheus metrics in a Grafana dashboard. Azure monitoring combines the best of open technology with the reliability of a cloud service.

In the last few years, KubeCon has grown from a single-track to many tracks and thousands of people. For me personally, and the community in general, it’s been an incredible journey. I’m excited to see people in San Diego – please stop by the Azure booth and say hello!