Thursday, November 11, 2021

Utilization of different Open-source software (OSS) in AKS on Azure Stack HCI

Olaseni_Adeniji_0-1636657921021.jpeg


Hi everyone! 
 

In May of 2021, we announced the release of Azure Kubernetes Service on Azure Stack HCI (AKS-HCI), an Azure service that is hybrid front and center, and a number of OSS projects at the core. This post covers some of the different OSS projects utilized in AKS-HCI and how we use them to empower our customers.  

 

Before I dive in, to recap, AKS-HCI is a turn-key solution for Administrators to easily deploy, manage Kubernetes clusters in datacenters and edge locations, and developers to run and manage modern applications just like they do with the Azure Kubernetes Service in Azure today.  The architecture seamlessly supports running your containerized Windows and Linux apps on top of an Azure Stack HCI, or Windows Server 2019/2022 Datacenter physical clusters. An AKS-HCI deployment comprises of several different layers, starting with a management cluster, which in turn is used to manage your target, or workload clusters, comprising of a load balancer, control plane and worker nodes. All of these run virtualized on top of your physical Azure Stack HCI or Windows Server-based clusters. For detailed information on each of these layers visit here. 

 

So, let us dive in at some OSS projects at the heart of AKS-HCI:  

 

Kubernetes: The first OSS project of focus today is Kubernetes, also popularly referred to as K8s. It is an open-source orchestrator for automating container management at scale. Microsoft has built the integration for Cloud Native Compute Foundation (CNCF) certified Kubernetes to work effectively with the underlying compute, storage, networking, and clustered infrastructure in Azure Stack HCI, and combines this with the Kubernetes open-source software to build our AKS-HCI solution today. Keeping up to date with the latest Kubernetes version is always top of mind for us. Read more about our Kubernetes solution here 

 

Calico & Flannel (Networking): Network Policy is defined in Kubernetes API as a specification and for AKS-HCI we have chosen Calico from the multiple solutions available as our default Container Network Interface (CNI) for new Kubernetes clusters. AKS-HCI supports both Flannel and Calico as CNIs. Read more here 

 

Prometheus and Grafana (Monitoring): We know monitoring the health, performance and resource usage of the control plane nodes and workloads on your cluster is important when you have applications running in production, we support both Prometheus and Grafana as on-premises monitoring and logging tools. We utilize Prometheus, a CNCF project that works with different types of collectors and agents to collect metrics and store them in a database where you can query the data and view reports and with AKS-HCI we can make it easy to deploy! You can use Grafana to query and visualize metrics on dashboards and can also configure Grafana to use Prometheus as the data source. Read more here 

 

ClusterAPI: The Cluster API (CAPI) brings declarative, Kubernetes-style APIs to cluster creation, configuration, and management. Utilizing this cloud provider/infrastructure provider model, we have been able to leverage the upstream work of clusterapi. Cluster API provider Azure Stack HCI (CAPH) is the CAPI infrastructure provider for Azure Stack HCI on-premises cloud deployments. It defines computational resources (e.g., machines, disks, networking, etc.) on an Azure Stack HCI cloud. CAPH consists of a set of Custom Resource Definitions (CRDs) which extend the base CAPI objects, and which are owned & operated on by a manager/controller. ClusterAPI is especially important to our hybrid story and is an area we are actively involved in the community. Read more here  

 

ContainerD (Container Runtime): ContainerD is now the default Container Runtime for our Linux Worker Nodes and is progress for Windows (we are actively working with containerD and kubernetes community to support containerD for Windows). We made this change for Linux Worker Nodes earlier in the year with AKS and it is also a response to the decision by Kubernetes to deprecate the use of Docker.  

 

Honorable mention:  

 

Container Storage Interface (CSI) drivers (Storage): Not open source but an open standard. The AKS-HCI disk and file Container Storage Interface (CSI) drivers are CSI specification-compliant drivers used by AKS-HCI. By adopting and using CSI, AKS on Azure Stack HCI can write, deploy, and iterate plug-ins to expose new storage systems or improve the existing ones in Kubernetes without having to touch core Kubernetes code and wait for its release cycles. The CSI storage driver support on AKS-HCI will allow you to use AKS-HCI disks, which can be used to create a Kubernetes DataDisk resource. Read more here 

 

This is a highlight of some of the OSS projects used in AKS-HCI, As I mentioned earlier, OSS is top of mind here on the AKS-HCI team – adopting, utilizing, and contributing to serve our customers and further the communities.  

 

To try out AKS-HCI see links below :smiling_face_with_smiling_eyes: 

 

Useful links: 

Try for free: https://aka.ms/AKS-HCI-Evaluate 
Tech Docs: https://aka.ms/AKS-HCI-Docs 
Issues and Roadmap: https://github.com/azure/aks-hci 
Evaluate on Azure: https://aka.ms/AKS-HCI-EvalOnAzure 

Posted at https://sl.advdat.com/30faViI