Key Differences between CAKS and Managed AKS
| Aspect | CAKS | MAKS |
|---|---|---|
| Architecture | Utilizes a single AKS cluster with namespace isolation for multiple clients. | Employs individual AKS clusters for each client, providing complete isolation. |
| Namespace Isolation | Uses namespace isolation within a single AKS cluster. Clients operate within designated namespaces. | Achieves isolation by deploying separate AKS clusters for each client. |
| Dynamic Provisioning of Volumes | Implements partial dynamic provision of volumes. Clients specify storage accounts. PVCs created over specified storage accounts. | Utilizes dynamic provisioning of volumes. AKS cluster automatically provisions storage resources. |
| Data Isolation | Clients keep storage in their own subscription. Data isolation from CAKS subscription. | Inherent data isolation. Each client's AKS cluster operates within its own subscription. |
| Management Overhead | Reduces management overhead. Centralizes workloads in a single AKS cluster. | Requires managing individual AKS clusters for each client. Increased monitoring and updates. |
| Scalability and Resource Utilization | Multiple clients share resources within a single AKS cluster. Dynamic allocation based on demand. | Scalability at cluster level. Dedicated resources for each client. Isolated resource utilization. |
| Multi-Tenancy | Namespace isolation within a single AKS cluster. Logical separation at namespace level. | Separate AKS clusters for each client. Physical isolation. Dedicated environments per client. |
| Security and Compliance | Enhanced security through namespace isolation and client-managed storage accounts. | Strong security boundaries. Isolation at cluster level. Simplified compliance and data sovereignty. |
| Resource Allocation and Optimization | Dynamic allocation of resources among multiple clients. Efficient utilization based on workload demands. | Granular control over resource allocation. Tailored configurations for specific workload requirements. |
| Cost Management | Potential cost savings. Centralized infrastructure and shared resources in a single AKS cluster. | Cost predictability. Dedicated resources per client in separate AKS clusters. |
Alerts and Monitoring in AKS
In Azure Kubernetes Service (AKS), alert configuration plays an important role in monitoring the health and performance of your clusters.
There are two types of alerts used in AKS:
- Nodepool Level Alerts
- Namespace Level Alerts
Here is an overview of alerts deployed in AKS
view of alert page
Nodepool Level Alerts
- These alerts are specific to a particular nodepool within an AKS cluster.
- They monitor resource utilization (CPU and memory) of individual nodes within the nodepool.
- When a threshold is exceeded (e.g., CPU usage greater than 95% or memory usage greater than 95%), the alert triggers.
- The associated action sends notifications to a designated action group
1. Node CPU Usage Alert
This alert triggers when at least one node in the nodepool has CPU usage greater than threshold (i.e. 95%).
2. Node Memory Usage Alert
This alert triggers when at least one node in the nodepool has Memory usage greater than threshold (i.e. 95%).
Namespace Level Alerts
- These alerts operate at the namespace level within the AKS cluster.
- They focus on specific aspects related to pods and deployments within a namespace.
- E.g. they include monitoring persistent volume (PV) usage and pod restarts.
- When certain conditions are met (e.g., more than one PVC using memory greater than 95% or more than one pod restarting excessively), the alerts activate.
- Similar to nodepool alerts, notifications are sent to the specified action group
1.Persistent Volume (PV) Usage Alert
This alert triggers when more than one PVC in the namespace is using memory greater than 95%
2. Pod Restart Alert
This alert triggers when more than one pod in the namespace is restarting more than 10 times.
3. Unhealthy Pod Alert
This alert triggers when more than one pod in the namespace is unhealthy.
4. Unhealthy Deployment Alert
This alert triggers when more than one deployment in the namespace is unhealthy.
All these alerts are associated with the aks action group. The alerts for PVC usage, pod restarts, pod health, and deployment health are muted for a duration of one day after they are triggered.
When an alert is triggerred, an email notification is sent to the respective stakeholders of the resources. Following is a sample email notification for such an alert:
The logs from the Log Analytics workspace are loaded into Azure Monitor using the OMS Agent
