Managing Kubernetes clusters at scale across a variety of infrastructures iswelleven harder.

The Kubernetes community project Cluster API (CAPI) enables users to manage fleets of clusters across multiple infrastructure providers. The Cluster API Provider for Azure (CAPZ) is the solution for users who need to manage Kubernetes clusters on Azure IaaS. In the past, we have recommended AKS Engine for this common scenario. While we will continue to provide regular, stable releases for AKS Engine, the Azure team is excited to share that CAPZ is now ready for users and will be our primary tool for enabling customers to operate self-managed Kubernetes clusters on Azure IaaS.

Do you manage your own Kubernetes clusters?

Kubernetes is the dominant cross-platform tool for managing containerized applications. Azure Kubernetes Service (AKS) is the managed service that makes it easy for users to run Kubernetes on Azure. AKS is mature, scalable, secure, and backed by Azure’s excellent support. But some users need to run clusters themselves and can't take advantage of AKS. Some need functionality that is not available in AKS yet or might never be because they require user access to the control plane.

Some are running a service themselves on Azure that leverages Kubernetes and needs complete control, and others might need to run their own clusters for compliance or regulatory reasons (for example, financial services companies who can’t delegate management to another organization). Still, other users are developing new integrations with Kubernetes or Kubernetes features themselves, and need to be able to tweak, control, and test anything and everything. We call these clusters that users run themselves "self-managed" clusters.

If you need to run self-managed clusters on Azure, whatever your reason, you've come to the right place.

Cluster API powers self-managed clusters on Azure

The Kubernetes community has long recognized the need for tooling to provide standardized lifecycle management of clusters independent of the infrastructure on which they run. In response SIG Cluster Lifecycle created the Cluster API sub-project:

Cluster API is a Kubernetes sub-project focused on providing declarative APIs and tooling to simplify provisioning, upgrading, and operating multiple Kubernetes clusters. – The Cluster API Book

Cluster API provides our team with a natural place to innovate in open source for users and expand community participation in solving Azure user problems at the same time. Thus, it made sense for us to spend the past 18 months investing in the Azure Provider for Cluster API (CAPZ) to make it a fully functional project ready to realize the vision of Cluster API for every user.

The most recent CAPZ release, v0.4.10, includes new capabilities such as GPU support, private clusters, and Azure API call tracing. Some of you may be reluctant to adopt a tool whose API is labeled alpha (v1alpha3 to be exact). You should take comfort in the knowledge that CAPI enables forward and backward compatibility of API versions so that when the project moves to v1alpha4, and then v1beta1, you'll be able to upgrade, and then use the API to output your objects with the new API version.

Our team is thrilled with the CAPZ work because more of you will be able to effectively manage your cluster's entire lifecycle on Azure. It has also been fulfilling to drive innovations in the Cluster API community, like CAPI MachinePool, which enables users to take advantage of each infrastructure provider's native VM scaling group capability. CAPI brings Kubernetes native cluster management and CAPZ enables this naturally on Azure infrastructure. Together in the community, we can deliver better capabilities for users more quickly.

Users are already taking advantage of CAPI and CAPZ on Azure. The Azure provider community consists of amazing people from Azure, VMware, Red Hat, Weaveworks, and more. Community members are realizing the power of the Cluster API by using CAPZ for use cases that span from building new platforms and products, like Tanzu Kubernetes Grid, to testing new hardware on multiple infrastructures.

Users are also discovering new use cases for CAPI. For example, a recent example uses CAPI and Helm to operate managed clusters. And our team is using CAPZ to validate new versions of, and features in, Kubernetes on Azure. Soon our upstream tests will move from using AKS Engine to CAPZ.

But what about AKS Engine?

Our team, Azure Container Compute Upstream, has the following mission:

• Enable Azure to efficiently consume innovations from the Kubernetes ecosystem
• Contribute innovations from Azure to the Kubernetes ecosystem

We maintain AKS Engine as an open source tool for Azure customers, but the narrow focus on Azure-specific APIs is inconsistent with our mission in the Kubernetes ecosystem.

AKS Engine works by creating ARM templates from a cluster model. ARM templates are a great Azure-specific solution for cluster creation, but this design falls short of empowering ongoing operational needs such as scaling, in-place upgrading, and extension management. And it isn't useful for users who are focused on multi-cloud scenarios like managing fleets of Kubernetes clusters across cloud infrastructures that do not support ARM.

AKS Engine users will continue to receive excellent community support. As more maintainers have joined the AKS Engine community the Upstream team has shifted focus to CAPZ for new Kubernetes features. The community is committed to integrating and validating new versions of Kubernetes into AKS Engine. AKS Engine will remain the tool for creating Kubernetes clusters on Azure Stack Hub. We encourage other AKS Engine users to evaluate moving to CAPZ as it already provides stronger support for managing the cluster lifecycle compared to AKS Engine, and new investments from the Upstream team will be focused there. If you are committed to using AKS Engine longer term and would like to become a project maintainer, please reach out to us!

Cluster API CAPZ: Getting started, getting help, and getting involved

To get started building Kubernetes clusters on Azure with CAPZ, try the amazing CAPZ documentation. When you have issues, please look at the CAPZ issues and create new ones if needed. If you want to get more involved in developing CAPZ, our team is active during office hours and invite your participation. Many also find the #cluster-api-azure Slack channel to be a great source of advice, help, and collaboration.

In our next blog we'll discuss in more detail how you can customize your CAPZ deployment to tune startup time for your application by baking your chosen operating system and patch level, and/or your application binaries and configurations into the virtual machine images. We plan to follow that with a discussion about how to leverage the GitOps principles by synchronizing a git repo with your management cluster. Reach out to us in the Kubernetes Slack (@craiglpeters and @jackfrancis) or on Twitter (@peterscraig and @jackfrancis_esq) with any other topic you'd like to see us dig into.

The post Introducing the Cluster API Provider for Azure (CAPZ) for Kubernetes cluster management appeared first on Microsoft Open Source Blog.

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!

The post Empowering cloud-native developers on Kubernetes anywhere appeared first on Microsoft Open Source Blog.

Just as important as the code responding to events, is the scaling of that code and compute. Kubernetes-based event-driven autoscaling (KEDA) is an open sourced component that can run in a Kubernetes cluster to provide event-driven autoscaling for every container. Today we are thrilled to announce a 1.0 version of KEDA that is ready for use in production.

Serverless scale within Kubernetes

Kubernetes provides a powerful container orchestration platform, but by default will only scale based on system metrics like CPU and memory. This means there can be a significant delay in a system’s ability to respond to events. Take an event like a message landing on a message queue. Thousands of queue messages may be sent and awaiting processing, but Kubernetes knows nothing about how many events are happening. Kubernetes will see the CPU and memory of the containers start to rise, but will take some time for the system to react. KEDA greatly improves this by enriching Kubernetes autoscaling with metrics on the rate of events.

With KEDA installed, Kubernetes now can know how many messages are arriving, and use that information to start to scale an app even before the CPU starts to rise. KEDA can assist Kubernetes to scale apps to and from zero as well. If an app is responding to an event that has been idle, KEDA lets Kubernetes know it can scale it to zero to prevent it from consuming any CPU when not needed.

We've worked closely with users and organizations during the preview who have been using KEDA around event-driven Kubernetes. Two notable examples are Swiss Re Asset Management and CycloMedia. Tom van de Meent, lead architect for CycloMedia, shared, "At CycloMedia we've been running Azure Functions with Azure Storage Queues in Kubernetes. KEDA has been helpful in adding dynamic scaling to handle these workloads.”

Developed in the open

We announced KEDA in collaboration with Red Hat back in April and have been delighted with the engagement from users and the community. With hundreds of merged pull requests, dozens of contributors, and weekly community calls, KEDA has only gotten better. KEDA now supports 13 event sources, including Azure Queues, Azure Event Hubs, AWS SQS, Google Cloud PubSub, RabbitMQ, NATS Streaming, Kafka, and more. KEDA also has an extensible gRPC contract so other scalers can be dynamically discovered to add additional capabilities. The community is also helping to build support on top of the popular Operator SDK for ease of installation and management in many environments including Red Hat OpenShift 4.

“Red Hat is working with the cloud-native community to enable portability of serverless applications in hybrid environments. Part of this effort is contributing to KEDA — both via the upstream project and by bringing its utility to customers using enterprise Kubernetes and containers with Red Hat OpenShift. We congratulate the community on reaching this milestone, and look forward to continued collaboration with Microsoft and others to help extend choice for developers that want to be able to build and deploy applications anywhere," said William Markito Oliveira, Senior Manager of Product Management, Red Hat.

We couldn't have gotten to this 1.0 milestone without the help from the community and look forward to continued effort and engagement. We recently presented KEDA as part of the serverless working group in CNCF and are in the process to nominate and donate KEDA to the CNCF as a sandbox project. We believe the best products are made in an open and inclusive way.

Serverless functions and serverless scale

While KEDA works with any container, you can pair KEDA with the open sourced Azure Functions runtime to enable additional serverless capabilities within Kubernetes. Azure Functions provides a programming model that can run anywhere: in a container running on-premises, fully managed in Azure, or in any Kubernetes cluster.

With Azure Functions, application developers don't need to worry about writing the code to connect, trigger, and pull from an event source like RabbitMQ, Kafka, or Azure Event Hubs. Instead, they focus only on the code and business logic. With the integrated Azure Functions tooling, you can take any Azure Function app and deploy it to Kubernetes alongside KEDA for event-driven scale and event-driven apps.

KEDA can also run alongside Virtual Kubelet and Azure Kubernetes Service Virtual Nodes. With Virtual Nodes you can spin up containers outside of the dedicated nodes for a cluster and run them on serverless containers. The combination of KEDA, Azure Functions, and Virtual Nodes brings event-driven serverless functions on top of on-demand compute for a powerful serverless platform.

I want to share my sincere appreciation for the response and involvement of the community on KEDA. If you haven't used KEDA, you can learn more at KEDA.sh or try a step-by-step QuickStart. We are excited with how KEDA fits into cloud-native and serverless applications and look forward to more to come in this space as we continue to partner with the community.

The post Kubernetes-based event-driven autoscaling (KEDA) 1.0 release appeared first on Microsoft Open Source Blog.

During conversations amongthe community at KubeCon + CloudNativeCon in Barcelona a few months ago, it became apparent that there needs to be more effort put into sharing knowledge across organizations. Windows containers are new relative to Linux containers. The combination of rapid advancement of both Kubernetes and Windows containers means that many questions arise when planning for the future. Adding to the challenge, the developers who work on the core technology are mostly employed by a handful of companies.

With this in mind, I'm excited to share that we're hosting the community in the Puget Sound area on July 26th for a meeting of the minds at the Microsoft Reactor in Redmond. Please join engineers from Microsoft, Google, AWS, Docker, VMware and more to talk about everything from why you might want to use Kubernetes to schedule Windows containers to the inner workings of the container runtime, networking, and storage interfaces and how they're evolving as Windows containers evolve.

Come join your colleagues and fellow community members in sharing your knowledge and get your questions answered. We'll first meet and greet over some coffee and snacks at 9:30 AM, then Taylor Brown will kick us off with a short talk about the state of Windows containers and how they fit into the Kubernetes ecosystem. Next, we'll figure out which topics float to the top, and break into tracks as necessary. Finally, at the end of the day we'll recap, and anyone interested can grab a refreshment and continue the community building conversations. For those who can't join us in person, we willdo what we can to answer any questions in this document.

If you can join us in person please sign upand share your thoughts on topics in this form.

The post Join us for the first Windows Containers in Kubernetes “Unconference” appeared first on Microsoft Open Source Blog.

Kubernetes is a container management platform. Real world applications and services typically contain multiple containers that get deployed across multiple servers. Kubernetes allows you to treat those servers as a pool of compute resources. It monitors the resource usage and needs to determine where and when containers should run and if new instances need to be added. It has many features that makes it easier for me to build systems made of many containers and keep my sanity.

As I'm learning to build systems using Kubernetes, I have found that it solves these problems well for me:

• Compute scheduling. By looking at the resource needs of a pod (which is one or more containers), the scheduler will find the right place to run it.
• Self-healing. If a pod crashes, a new one will be created to replace it.
• Horizontal scaling. When the resource limits of a pod indicate the number of instances should increase, Kubernetes will add new instances, and it can do the same with decreasing instance count when resources drop.
• Volume management. It manages the persistent storage for needed by my applications.
• Service discovery & load balancing. Pods get their own IP address, DNS and multiple instances get load balanced.
• Automated rollouts & rollbacks. The health of the pods is monitored during updates, and if a failure occurs, the pod can roll back to the previous version.
• Secret & configuration management. Configuration and secrets are managed at the platform level that is used by the containers.

Of course, there are some things needed that are not part of Kubernetes. It needs to run on a platform that handles security, governance, identity and access control, networking, data and storage. We have chosen Azure for our hosted Kubernetes provider, but all the large cloud vendors offer a hosted version these days.

Choosing a hosted Kubernetes provider has shrunk my learning curve by allowing me to focus on managing my application (and not learning Kubernetes The Hard Way).

Besides hosting these multiple container systems, developing them has its own challenges. However, I've found the latest round of tools have features for native container development which makes it easier.

I must admit, I am most familiar with Microsoft's tools, so I’ll focus on those here:

• Visual Studio and Visual Studio Code both have extensions to help me work with Docker and Kubernetes without me needing to jump in and out of my IDE or editor.
• Azure Container Registry gives me a private registry to keep my container images and the Helm charts I use for deploying to Kubernetes.
• Azure DevOps Pipelines is super flexible and works great with my source code repository to build my container images and store them in my registry. It also is great for deploying to my different Kubernetes environments.
• Azure Dev Spaces helps me debug my containers that are deployed in Azure Kubernetes Service, as opposed to having to duplicate a local setup in order to reproduce the problem.

If you are also learning Kubernetes, here are a couple of resources that I’ve found to be useful: k8slearning and https://aka.ms/LearnKubernetes.

Questions or comments? Let me know in the comments below.

The post Kubernetes: What it is and what it isn’t appeared first on Microsoft Open Source Blog.

Why Helm?

Many teams already rely on Helm 2 to deploy and manage their applications on Kubernetes, the open source project that has become the de facto open source distributed systems kernel. Kubernetes usage is reportedly above 70% in large organizations as of 2018. At Microsoft, we see customer uptake of the managed Azure Kubernetes Service growing rapidly, and a great deal of our industry is focused on this space.

Kubernetes orchestrates containers, typically as a collection of services that together enable a microservice application in which various services work together to provide a larger experience. To host these workloads, many different Kubernetes components must be configured. In addition, Kubernetes has no built-in concept of an application as a logical, manageable unit, which makes application operations more difficult unless an organization dedicates staff to focusing on those primitives.

Typically, we prefer to make it simpler for cluster users to deploy and manage their applications as logical units in a self-service fashion. That's where Helm adds value!

Helm is the package manager for Kubernetes applications

Last year, the CNCF's cloud native survey made it clear that the "preferred method for packaging is Helm (68%) followed by managed Kubernetes offerings (19%)." Users find that Helm is a great way to:

• Manage complexity: describe complex Kubernetes applications in a "chart."
• Share charts: search for shared charts on public and private chart repositories.
• Easily update Kubernetes applications: in-place upgrades and rollbacks (which are actually roll-forwards; Helm doesn't include time travel!) to past versions, using the release history of charts.

Making complex things easier to manage is the hallmark of a good tool and the strong adoption of Helm shows us that many people are looking for this kind of tooling.

Helm 3 is built for production scenarios in mind

Adventure. Excitement. An on-call engineer craves none of these things operational surprises don't help us sleep at night. Predictable and repeatable production-ready software we can operate at scale is delightful and that's why we create tools like Helm.

If you're using Helm already, try Helm 3 today to help the community ensure there are no surprises for your use cases. Helm 3 is the result of years of community contributions and conversations that clearly show how organizations are using Helm and how they need it to evolve for their production use cases.

Even if Helm is new for you, your input is welcome! Take a look at Helm 3 and find out how Helm charts help you bring operational simplicity and enterprise-ready stability to your Kubernetes environments.

Simpler to use, more secure to operate

Wasn't Helm 2 already simple? If we install the same Helm chart with Helm 2 and Helm 3, the application installed will be precisely the same, just as we would expect! So, what's the motivation behind Helm 3?

Tiller, the server-side component of Helm 2, requires additional security steps and Helm 2 was created for developers to install applications when Kubernetes did not yet have role-based access control (RBAC). This complexity isn't needed in recent releases of Kubernetes, so for Helm 3 we were able to remove tiller entirely.

As a result, Helm 3 is significantly simpler, while also supporting all the modern security, identity, and authorization features of today's Kubernetes. Helm 3 allows us to revisit and simplify Helm's architecture, due to the growing maturity of Kubernetes identity and security features, like role-based access control (RBAC), and advanced features, such as custom resource definitions (CRDs).

Join the cloud-native fun!

We're so excited for what Helm 3 will allow you to do! You can read about all the new features, such as chart reuse in chart libraries, in the blog series Helm 3: Charting Our Future and join the discussion on GitHub to make this major release the best Helm for you. We're looking forward to connecting during sessions and deep-dives at KubeCon EU this week and can't wait to hear your feedback on the alpha version.

Your feedback is invaluable, as the Helm community intends to make Helm 3 generally available (GA) at Helm Summit EU in September. Come share your stories and continue the conversation!

The post Helm 3: simpler to use, more secure to operate appeared first on Microsoft Open Source Blog.

These conferences are fantastic because they represent an opportunity to meet with our users and learn about how our software is both making them more successful and also hindering their success. While learning about how we empower developers is awesome, it's even more important (and significantly more humbling) to learn about the areas where they have unmet needs, have hit bugs, or are otherwise blocked by choices we've made or bugs that we've written.

Listening to our users and customers and focusing our energy on solving their real-world problems is the #1 (and #2 and #3) focus for my teams. In that spirit, I'm excited to announce: the Helm 3 release, Kubernetes integration with Visual Studio Code (VS Code), the Virtual Kubelet project 1.0 release, and the Service Mesh Interface (SMI), which is our new community project for collaboration around Service Mesh infrastructure.

Helm 3

The first, and arguably most significant for the Kubernetes community, is the first Alpha release of Helm 3. Helm 3 represents a nearly complete re-factoring of the Helm package manager to evolve it from its origins to a modern application package manager. The Helm project is nearly as old as Kubernetes itself. As a result, its original design pre-dated many advancements in Kubernetes like CustomResourceDefinitions and even Kubernetes RBAC.

Because of this, the Helm 2 architecture was forced to implement a number of features itself, which made it less tightly integrated with Kubernetes, and meant that managing things like RBAC of Charts and Resources was complicated and disconnected from Kubernetes itself. Helm 3 eliminates this impedance mismatch.

By replacing custom APIs for charts and deployments with CustomResourceDefinitions, things like Kubernetes RBAC directly apply to Helm and the whole system feels significantly more tightly-integrated and Kubernetes-native. You can now use the 'kubectl' command line to interact with your Helm charts and Kubernetes native RBAC to limit access and resources that users can create.

Helm has become the defacto standard for packaging and deploying Kubernetes applications by focusing on the end-user and enabling those users to be successful. The advances and improvements in Helm 3 continue this trend and make it even more useful to both existing users, as well as others who may have previously tried other solutions. Many congratulations to the Helm project and community on reaching this milestone!

Kubernetes extension for Visual Studio Code

Making Kubernetes accessible to everyone is a challenge that I think about every day. It's great that we've built a system that makes it easier to deploy distributed systems, but if we haven't made it possible for everyone to use Kubernetes then we've actually failed. In that vein I have spent a bunch of time recently working with the team that builds the open source Kubernetes extension for Visual Studio Code.

This extension brings native Kubernetes integration to VS Code. You can easily view the contents of your cluster, see the state of pods at a glance, right-click to get a terminal in a Pod or port-forward network traffic, and easily filter your way through logs to identify problems all within the exact same environment where your code lives.

Furthermore, in keeping with our open principles, the extension is open source on GitHub and works with Kubernetes anywhere. No matter where you are running Kubernetes, the VS Code integration makes it easier to work with your applications and clusters with fewer windows and context switches.

Today at KubeCon EU in Barcelona, I'm excited our VS Code integration has reached the 1.0 milestone and is fully supported for production management of your Kubernetes clusters. Even more importantly, we've also added an extensibility API that makes it possible for others, like Red Hat OpenShift, to build their own integration experiences on top of our baseline Kubernetes integration. ('yo dawg, I heard you like extensions, so I added extensibility to your extension.') Much like Custom Resources, adding extensibility enables collaboration at the core while enabling others to build rich experiences targeted to specific environments. It's a testament to the value of an open and extensible approach to tooling.

Virtual Kubelet 1.0

Speaking of community, I'm also incredibly excited to see the Virtual Kubelet hit the 1.0 milestone. The Virtual Kubelet represents a unique integration of Kubernetes and serverless container technologies, like Azure Container Instances. Enabling people to free themselves from the toil of managing an operating system, while still using Kubernetes for orchestration, is a powerful value proposition to startups and enterprises alike.

I'm really excited that this community is healthy and reaching this important milestone, and that Azure was able to play a role. Earlier this month at //build we also announced the general availability of AKS virtual nodes powered by the open source community code in the Virtual Kubelet project. Again, showing the value of open source even when delivering tightly integrated features for Azure.

Service Mesh Interface (SMI)

Finally, I'm thrilled to see the community that is developing around the Service Mesh Interface specification. It has been clear to us for a while that users and customers are excited by the promise of Service Mesh to provide the next advances in cloud-native application development. However, it is also clear that the monolithic integration of interface and implementation that previously existed for Service Mesh has limited their adoption.

The world of Service Mesh is fast and evolving and users are concerned that if they are locked to any particular implementation, they may be locked into a complex surface area. By providing a generic API interface that is then implemented by various service mesh providers, like Istio, Linkerd, and Consul Connect, the Service Mesh Interface frees users to use service mesh capabilities without being bound to any particular implementation.

This means that they are free to experiment, and even change implementations without having to change their applications. This brings Service Mesh on parity with other parts of Kubernetes, like Ingress, Container Runtime (CRI), and Networking (CNI), which all have generic interfaces with pluggable implementations. We've really enjoyed working with our great partners on the SMI specification and we look forward to building an even larger community as we move forward and iterate on the specification.

Enjoy KubeCon and Barcelona (and make sure to check out the Sagrada Familia). The Azure team is will be busy learning from you, our community, so we can build the next set of great products and features that make you even more productive and happy!

Questions or feedback? Let us know in the comments below.

The post Extending Kubernetes in the open appeared first on Microsoft Open Source Blog.

In contrast, services like Azure Functions are acutely aware of event sources and therefore able to scale based on signals coming directly from the event source, even before the CPU or memory are impacted. We set out to bring the benefits of event-driven architectures and the productivity of functions to Kubernetes. The result is KEDA Kubernetes-based event-driven autoscaling.

Microsoft and Red Hat partnered to build this open source component to provide event-driven capabilities for any Kubernetes workload.KEDA enables any container to scale from zero to potentially thousands of instances based on event metrics like the length of a Kafka stream or an Azure Queue.It alsoenables containers to consume events directly from the event source instead of decoupling with HTTP. KEDA can drive the scale of any container and is extensible to add new event sources.

Because Azure Functions can be containerized, you can now deploy functions to any Kubernetes cluster while maintaining the same scaling behavior you would have in the Azure Functions service.For workloads that may span the cloud and on-premises, you can now easily choose to publish across the Azure Functions service, in a cloud-hosted Kubernetes environment, or on-premises. Our partnership with Red Hat enables Azure Functions to run integrated within OpenShift, providing the productivity and power of serverless functions with the flexibility and control to choose where and how to host it. The same application can move seamlessly between environments without any changes to development, code, or scaling.

Bringing rich events into Kubernetes workloads

KEDA provides a FaaS-like model of event-aware scaling, where deployments can dynamically scale to and from zero based on demand. KEDA also brings more event sources to Kubernetes. When we think about event–driven scenarios, the first event source we oftenconsideris an HTTP event. However, we’ve learned from running Azure Functions that only 30% of our executions are coming from HTTP events, while the majority come from other event sources. We wanted to make sure that those other 70% of event executions were handled in a natural way in Kubernetes with KEDA.

While other Kubernetes offerings have attempted to bring events from other sources, they usually involve converting the event to an HTTP request, which means data and context is lost in the process and direct communication with the event source is limited. KEDA unlocks rich connectivity directly to the event sources, enabling rapid and proactive scaling while preserving direct interaction with the event. KEDA provides a key component for event-driven and cloud native apps, and it also works seamlessly alongside Virtual Kubelet and AKS Virtual Nodes, letting you to run your event-driven apps on serverless containers.

Running Azure Functions in any environment

Thousands of customers have already been using Azure Functions as the serverless compute service to process billions of events every day. Azure Functions provides an unmatched development experience, allowing you to develop and debug functions locally on any platform using editors like Visual Studio, Visual Studio Code, and more. While Azure Functions provides a fully managed serverless service, many customers want the freedom to run serverless in an open environment they can manage.

With the release of KEDA, any team can now deploy function apps created using those same tools directly to Kubernetes. This allows you to run Azure Functions on-premises or alongside your other Kubernetes investments without compromising on the productive serverless development experience. The open source Azure Functions runtime is available to every team and organization, and brings a world-class developer experience and programming model to Kubernetes.

The combination of flexible hosting options and an open source toolset gives teams more freedom and choice. If you choose to take advantage of the full benefits of a managed serverless service, you can shift responsibility and publish your apps to Azure Functions. If it makes sense for your organization or scenario, you can choose to run those same apps in Kubernetes with KEDA. While the hosting may vary, the developer experience and scaling remains constant.

You can publish your first Azure Function to Kubernetes by following this simple tutorial.

Compatible with every event source

KEDA will automatically detect new deployments and start monitoring event sources, leveraging real-time metrics to drive scaling decisions. Today KEDA and supporting tooling works with Kafka, Azure Queues, Azure Service Bus, RabbitMQ, HTTP, and Azure Event Grid / Cloud Events. More triggers will continue to be added in the future including Azure Event Hubs, Storage, Cosmos DB, and Durable Functions. KEDA event sources are extensible and we look forward to many additions from the community.

KEDA is open source on GitHub and open to community contributions. We look forward to hearing feedback from the community and working together to make event-driven container scale available to every developer and for every event type. If you want to learn more about KEDA, register today for our webinar later in May where we can share more on the benefits of event-driven and serverless architectures.

Questions or feedback on this news? Please let us know in the comments below.

The post Announcing KEDA: bringing event-driven containers and functions to Kubernetes appeared first on Microsoft Open Source Blog.

Over the past few years, the service mesh has risen to become a critical element of the cloud native stack. The first service mesh project, Linkerd, joined the Cloud Native Computing Foundation just last year, and has since grown to power the production infrastructure of companies around the globe, ranging from startups, like Monzo and OfferUp, to well-established companies, such as Comcast and Salesforce. Meanwhile, a host of other projects have followed hot on its heels, from cloud providers and startups alike. (See this video by Azure's Lachlan Evenson on installing and run Linkerd 2.0 on Azure Kubernetes Service.)

In this article, we'll define the service mesh and explain the various factors that are enabling the rise of service mesh adoption. Finally, we'll provide a vision of where the service mesh is heading.

What is a service mesh?

At its heart, a service mesh is a distributed set of proxies that are deployed alongside microservices. Following common network terminology, these proxies are often referred to as the data plane, and are typically coordinated by a centralized component called the control plane. Critically, the data plane proxies handle both incoming and outgoing traffic for each microservice, typically without the application code even being aware.

The data plane proxies act as highly instrumented, out-of-process network stacks, and handle all traffic to and from a microservice. Because they're centrally controlled, the service mesh can institute a variety of traffic control techniques globally across the application that provide reliability, observability, security, and more.

For example, the proxies can instrument all calls to a service, and provide "golden metrics," such as success rates, latency distributions, and request volumes to that service, or even to individual paths. They can handle request retries and timeouts. They can encrypt communication transparently with TLS. And they can accomplish all these things without any involvement from the application itself.

Why use a service mesh?

For an industry that's focused on speed and performance, the idea of adding user-space proxies in between every inter-service call can seem counterintuitive. Why introduce this new layer of complexity and latency?

The reason is more than the individual features. The service mesh provides something vital to operators: the ability to shiftresponsibility for much of the reliability, visibility, and security requirements out of the application code itself, down onto the underlying infrastructure. This shift means the platform itself can provide these features without developer involvement.

This decoupling of responsibility, and ability to provide reliability, visibility, and security globally across the application, are the fundamental value proposition of the service mesh.

Why are service meshes becoming so popular?

The rise of service meshes, such as Linkerd, is tied to a big shift in the industry: the adoption of cloud native architectures, in which an application is built as microservices, deployed as containers, and run on a container orchestration system, such as Azure Kubernetes Service (AKS).

The cloud native approach, in turn, is rapidly gaining popularity because it is uniquely suited to the increasingly strict demands that we place on our software systems. In the modern world, we expect our software applications to be resilient to failures in hardware, software, and network, as well as handle massive scale and maintain a breakneck pace of feature development. This is a far cry from the expectations we placed on software a decade ago, when "sorry, we're down for maintenance" was acceptable!

The adoption of microservices especially allows us to meet those demands not only at the technological level, but also at the organizational level. By breaking our applications into loosely-coupled microservices that can be developed and released independently of each other, we isolate our failure domains and provide ways for the application to remain functional even if individual components are failing. More importantly, we also remove organizational bottlenecks and allow our developers to iterate with a minimum of coordination required.

These changes in organization and software architecture require new types of tooling to provide visibility into what is happening; new ways to manage partial failures and prevent them from escalating into full-blown ones; and new ways to address policy for security and compliance. The service mesh is part and parcel of these changes.

The service mesh today

While many companies have adopted the service mesh as a critical component of their application infrastructure, the service mesh landscape today is still nascent and continues to evolve rapidly. A heady mix of assorted service mesh projects from cloud providers and startups alike have served to validate the approach, but the bewildering array of options can also be confusing.

As the CNCF service mesh project, and the project that "started it all," Linkerd has had the best opportunity to learn from its community of adopters and contributors around the world. Based on these lessons, much of the recent focus has been on dramatically reducing the amount of complexity introduced by the service mesh, following the mantra of "less is more." The recent release of Linkerd 2.0, focused on zero-config installation process and ultralight, Rust-based proxies, has demonstrated that adding a service mesh to an existing system doesn't require inordinate amounts of configuration, conceptual overhead, or system resources.

As with all early technology patterns, the service mesh will continue to evolve rapidly over the next few years. It is, in the words of Kubernetes maintainer Tim Hockin, “an exciting time for boring infrastructure."

Linkerd has a thriving community of adopters and contributors, and we'd love for YOU to be a part of it. For more, check out the docs and GitHub repo, join the Linkerd Slack and mailing lists (users, developers, announce), and, of course, follow @linkerd on Twitter. We can't wait to have you aboard.

Questions or feedback? Let us know in the comments.

The post What is a service mesh anyways? appeared first on Microsoft Open Source Blog.

Azure Kubernetes Service (AKS) makes it simple to deploy a managed Kubernetes cluster in Azure. AKS reduces the complexity and operational overhead of managing Kubernetes by offloading much of that responsibility to Azure and handling critical tasks like health monitoring and maintenance. However, your operational needs may require you to deploy your Kubernetes cluster in a hybrid setting. For instance, your data services may be running in your private cloud while application logic services could be running in AKS.

Without the proper toolset and configuration, maintaining visibility and security for your distributed environment can be hard to configure and maintain. In this blog, we focus on providing centralized visibility and monitoring for these types of distributed workloads in a manner that is easy to deploy and manage. By following step 5 in the blog below, you will learn how to easily enforce network and service layer access policies in your AKS cluster with Aporeto. You may extend these policies in a hybrid environment without any network configuration or code modification.

About Aporeto

Aporeto is a Zero Trust security solution for microservices, containers and cloud. Fundamental to Aporeto's approach is the principle that everything in an application is accessible to everyone and could be compromised at any time. Aporeto uses vulnerability data, identity context, threat monitoring and behavior analysis to build and enforce authentication, authorization and encryption policies for applications. With Aporeto, enterprises implement a uniform security policy decoupled from the underlying infrastructure, enabling workload isolation, API access control and application identity management across public, private or hybrid cloud.

Because Aporeto transparently binds to application components to provide them with identity, the result is security independent from infrastructure and network and reduction of complexity at any scale on any cloud.

How Aporeto works

• Pick an application and visualize it;
• Generate and simulate security policy;
• Enforce the security policy.

You can visualize the application of your choice by deploying Aporeto as an AKS DaemonSet (see #A in diagram above). If you control the virtual machines on which your application component run, you may also deploy Aporeto as a Docker container or a userland process (see #B in diagram above).

Aporeto auto-generates application security policy by ingesting Kubernetes Network Policies and RBAC. You also have the option of leveraging your application dependency graph that Aporeto creates to describe the application's behavioral intent as policies. In every case, you may audit and edit auto-generated policies and inject human wisdom when necessary.

Once you have policies, you may simulate their enforcement at runtime to evaluate the effects of your security policies without interrupting operations. When satisfied that your security policies are solid, you may lockdown your application and protected it with a Zero Trust approach.

Because Aporeto untethers application security from the network and infrastructure, one key benefit of Aporeto's approach for protecting your containers, microservices and cloud applications is that you can have a consistent security approach even in a hybrid or multi-cloud setting. As you gain experience with Aporeto in a single cluster setting, you will quickly realize how easy it is to have a consistent security posture in multi-cluster and multi-cloud settings without any infrastructure or operational complexity.

Five Steps to Enforce Network and Service Layer Access Policies in AKS Clusters

Step 1: Prepare environment

You will need the following binaries installed in your path.

1. az (see https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest)
2. kubectl (see https://kubernetes.io/docs/tasks/tools/install-kubectl/)

Step 2: Setup Aporeto

Using a browser login to https://console.aporeto.com/ then select the desired namespace where the cluster will be placed. The select and expand “System” and then select “Kubernetes Clusters”. Click on the “+” icon (top right). Give the cluster the name “aks1” and leave all defaults as they are. Click on create. This will create the cluster and cause a file with the name aks1.tar.gz (assuming you named the cluster aks1) to be downloaded to your browser download directory. Take note of this file as we will need it later.

Step 3: Create AKS (Kubernetes Cluster on AKS)

If you have not already done so, log into Azure with the following Powershell or Bash commands:

az login

Then create a working directory with the following Powershell or Bash commands:

mkdir -p aks; cd aks

Move the file downloaded in the previous step into the working directory.

Create the Kubernetes cluster on AKS with the following Powershell or Bash commands.

az group create --name aporeto_lab --location eastusaz aks create --resource-group aporeto_lab --name aks1 --node-count 2 --generate-ssh-keysaz aks get-credentials --resource-group aporeto_lab --name aks1 -f kube.cfg

Set the kubectl config file in the environment.

With PowerShell

$loc = Get-LocationSet-Variable -Name "KUBECONFIG" -Value "$loc/kube.cfg"

With Bash

export KUBECONFIG=$PWD/kube.cfg

and then verify that the nodes are operational with the following Powershell or Bash commands:

kubectl --kubeconfig kube.cfg get nodes

you should see something like this:

->kubectl get nodesNAME STATUS ROLES AGE VERSIONaks-nodepool1-82983338-0 Ready agent 3m v1.9.6aks-nodepool1-82983338-1 Ready agent 3m v1.9.6

Step 4: Join the AKS Cluster to Aporeto

Extract the contents of the file aks1.tar.gz and create the kubernetes resources with the bash commands (or Powershell equivalent. This may require a utility such as 7zip).

mkdir -p kube_aporetotar xfv aks1.tar.gz -C kube_aporetokubectl create -f kube_aporeto

then check the status with the command:

kubectl get pods -n kube-system

you should see something like:

->kubectl get pods -n kube-systemNAME READY STATUS RESTARTS AGEaporeto-enforcer-fkf46 1/1 Running 0 23saporeto-enforcer-v4k5r 1/1 Running 0 23saporeto-kubesquall-h4m5d 1/1 Running 0 21sazureproxy-79c5db744-t2654 1/1 Running 2 4mheapster-55f855b47-drbb2 2/2 Running 0 3mkube-dns-v20-7c556f89c5-mcg6z 3/3 Running 0 4mkube-dns-v20-7c556f89c5-xhts7 3/3 Running 0 4mkube-proxy-h5rqq 1/1 Running 0 4mkube-proxy-s7rkq 1/1 Running 0 4mkube-svc-redirect-92tvv 1/1 Running 0 4mkube-svc-redirect-h2dmp 1/1 Running 0 4mkubernetes-dashboard-546f987686-7gzln 1/1 Running 2 4mtunnelfront-66fd996c74-dlpdm 1/1 Running 0 4m

Step 5: Roll up your sleeves and dig in with a demo app

Clone the github repo https://github.com/aporeto-inc/apowine.git and then follow the instructions in the README.md file. By following this tutorial, you will learn how to enforce network and service layer access policies in your AKS cluster.

Enjoy your AKS Cluster with Aporeto Security!

Now that you have connected your AKS Kubernetes cluster to Aporeto, you can visualize it in real time and on historical bases using the Aporeto UI (https://console.aporeto.com/). You can also connect your private cloud workload to your Aporeto account and view your distributed application's end-to-end operations centrally.

You can find instructions for connecting non-AKS workloads to Aporeto by perusing the document set in https://console.aporeto.com/accounts/welcome (click on “Switch to Accounts” (top right corner user icon, immediate right of the "?" mark icon). As always, you can request support directly in Aporeto's Console or via this link.

Aporeto's powerful security capabilities unlock the following use cases, among others:

• Network segmentation and workload isolation, reducing compliance scope
• Protection against malicious application discovery
• Transparent encryption without code or network modification
• Uniform API access control policy across services in public or private cloud
• Continuous vulnerability analysis of container images
• Runtime threat detection and protection based on behavioral analysis

To learn more, please visit https://www.aporeto.com/demo/

Enjoy!

The Aporeto Team

Questions or feedback? Let us know in the comments below.

The post Securing Kubernetes workloads in hybrid settings with Aporeto appeared first on Microsoft Open Source Blog.