Enable TLS on HTTP Triggered Function App in Kubernetes Using KEDA and NGINX
Sep 26, 2020 · 4 min read
With KEDA (Kubernetes-based Event-Driven Autoscaling), you can host Azure Functions on Kubernetes. KEDA allows you to scale pods based on configurable rules that rely on metrics from data sources such as Azure Queue. The Microsoft documentation outlines how you can use the Prometheus scaler to scale HTTP triggered Azure functions. However, it does not discuss the the security of the transport channel in detail. This quick tip will demonstrate how you can expose your HTTP triggered Azure Functions over TLS/SSL (HTTPS endpoint).
Read more of Enable TLS on HTTP Triggered Function App in Kubernetes Using KEDA and NGINX
Dynamic Admission Control in AKS with Azure Functions
Sep 20, 2020 · 15 min read
This article is part of #ServerlessSeptember. You’ll find other helpful articles, detailed tutorials, and videos in this all-things-Serverless content collection. New articles from community members and cloud advocates are published every week from Monday to Thursday through September. Find out more about how Microsoft Azure enables your Serverless functions at https://docs.microsoft.com/azure/azure-functions/. Nov 02,2020: The implementation of validating webhook Azure Function that uses Azure Communication Service is available in the feature/impl-azure-comm-service branch.
Read more of Dynamic Admission Control in AKS with Azure Functions
Istio Succinctly
Apr 21, 2020 · 4 min read
I am super happy to announce the release of my new eBook: Istio Succictly, published by Syncfusion. You can grab a copy of the book for free by clicking this link. If you are familiar with Kubernetes and want to augment your Kubernetes clusters with the most popular Service Mesh implementation, Istio, then this book is for you. In Istio Succinctly, we have tried to comprehensively cover the quintessence of Istio without sacrificing the necessary concepts and theory behind it.
Durable Cloud Event Production from Knative Container Source with Azure Durable Task Framework
Jan 15, 2020 · 11 min read
Knative is an excellent platform for building, deploying and managing serverless workloads on Kubernetes. The Serving resources of Knative extend Istio to support serverless applications. Another class of resources of Knative called Eventing extend Istio to support the production and consumption of Cloud Events. Knative offloads the responsibility of scaling the workloads from the users by only activating pods when they receive a request. It scales out the workload pods based on the number of requests and scales pods down to zero when they are idle.
Origin Authentication and RBAC in Istio with Custom Identity Provider
Nov 11, 2019 · 15 min read
The concept of access control can be boiled down to two factors: authentication (AuthN) and authorization (AuthZ). While authentication determines the identity of a client based on the data presented to the identity provider (e.g., Google and Microsoft AD), authorization determines whether an authenticated principal may interact with the resource. I am not going to delve deep into the security architecture of Istio since I have covered this topic in detail in my upcoming FREE quick start guide on Istio.
Read more of Origin Authentication and RBAC in Istio with Custom Identity Provider
Using CoreDNS to Conceal Network Identities of Services in Istio
Oct 31, 2019 · 11 min read
A crucial feature of the Istio Service Mesh is that it grants you absolute control over how you want to route traffic to a service. Each service on the Istio service mesh has a unique network identity that it receives from the underlying host, i.e., Kubernetes. For example, a service named foo provisioned in a namespace named bar will have the FQDN (Fully Qualified Domain Name) foo.bar.svc.cluster.local, which also serves as its network identity.
Read more of Using CoreDNS to Conceal Network Identities of Services in Istio
Appropriately Release Resources From DotNet Core Application Deployed in Kubernetes Cluster
Sep 08, 2018 · 4 min read
You have deployed your DNC (Dot Net Core) application on your Kubernetes cluster and to make it efficient, you have initialized resources, kept a database channel open, and did a ton of other things during the initialization of your application. Did you miss something? One of the critical tasks that you must do is cleaning up the resources, shutting down the open channels, and gracefully shutting off what you turned on and so on from your application when Kubernetes instructs your container to shut down.