AKS Q&A – 2

What’s the difference between development Kubernetes environments and production systems?

A: Development environments like Minikube, k3s, kind, k3d, and micro-k8s are designed for local testing and learning, but they’re not suitable for production use. In fact, Minikube’s official documentation specifically states it’s “just a local Kubernetes cluster and should not be used in production.”

In production environments, organizations use either:

• Self-managed Kubernetes clusters
• Enterprise Kubernetes distributions
• Managed Kubernetes services

What is a Kubernetes distribution?

A: A Kubernetes distribution is similar to a Linux distribution – it takes the open-source Kubernetes platform and enhances it with additional features, support options, and management tools.

Think of it like this:

• Linux → Linux distributions (Ubuntu, RedHat, Amazon Linux)
• Kubernetes → Kubernetes distributions (OpenShift, Rancher, EKS, AKS)

The main advantage of using a distribution is support. If you encounter issues with plain Kubernetes, you’re reliant on community support with no guaranteed timeline. With a paid distribution, you get dedicated support with faster resolution times.

What are the most popular Kubernetes distributions used in production?

A: Based on research, here’s the order of popularity:

1. Plain Kubernetes – Many organizations still use vanilla Kubernetes in production
2. Red Hat OpenShift – An enterprise Kubernetes platform with additional developer tools
3. Rancher – A complete Kubernetes management solution
4. VMware Tanzu – VMware’s Kubernetes platform
5. Cloud provider managed services:
   • Amazon EKS (Elastic Kubernetes Service)
   • Azure AKS (Azure Kubernetes Service)
   • Google GKE (Google Kubernetes Engine)
   • Docker Kubernetes Engine

What’s the difference between using plain Kubernetes vs. a managed service like EKS?

A: When you install Kubernetes yourself on EC2 instances:

• You’re fully responsible for managing the cluster
• AWS provides no support for Kubernetes issues
• You handle all maintenance, upgrades, and troubleshooting

When you use EKS:

• AWS manages the Kubernetes control plane
• You get AWS support for Kubernetes issues
• AWS handles maintenance and upgrades of the control plane
• You pay extra for this managed service

Both use Kubernetes under the hood, but EKS adds management capabilities and support.

Why do some companies still use vanilla Kubernetes instead of managed services?

A: There are several reasons:

1. Cost considerations: Managed services like EKS charge additional fees beyond the infrastructure costs.
2. Scale: Organizations with hundreds of clusters or thousands of developers would face enormous costs using managed services for all environments.
3. Control: Some organizations prefer complete control over their infrastructure without depending on a cloud provider’s implementation.
4. Non-critical timelines: Not all organizations require immediate support for all issues – some can work with community support timelines.
5. Development/staging environments: Many organizations use vanilla Kubernetes for non-production environments while using managed services for production.

How does AKS compare to other Kubernetes distributions and services?

A:

Feature	AKS	EKS (AWS)	GKE (Google)	Self-managed K8s
Control plane management	Managed by Azure	Managed by AWS	Managed by Google	Self-managed
Control plane cost	Free (pay only for nodes)	Charged per cluster	Free for standard, charged for Autopilot	Cost of infrastructure
Integration	Deep integration with Azure services	Deep integration with AWS services	Deep integration with GCP services	Manual integration required
Identity management	Azure AD integration	AWS IAM integration	GCP IAM integration	Manual configuration
Networking	Azure CNI, kubenet	AWS VPC CNI	GKE VPC-native	Various CNI options
Monitoring	Azure Monitor, Container Insights	CloudWatch, Container Insights	Cloud Monitoring, Cloud Logging	Manual setup required

What are the prerequisites for using AKS?

A: Before creating an AKS cluster, you need:

1. Azure subscription – Active subscription with contributor or owner permissions
2. Azure CLI installed (or use Azure Cloud Shell)
3. Resource provider registration for:
   • Microsoft.ContainerService
   • Microsoft.Network
4. Service Principal or Managed Identity for cluster operations (can be created during deployment)
5. Knowledge of networking requirements (VNet, subnets, etc.)

Can you provide a step-by-step guide for setting up an AKS cluster?

A: Here’s how to create a basic AKS cluster:

1. Install Azure CLI (if not using Cloud Shell):

# For Ubuntu/Debian
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

Login to your Azure account:

az login

Set your subscription (if you have multiple):

# List subscriptions
az account list --output table

# Set the desired subscription
az account set --subscription <subscription-id>

Create a resource group:

az group create –name myAKSResourceGroup –location eastus

Create an AKS cluster:

az aks create \
  --resource-group myAKSResourceGroup \
  --name myAKSCluster \
  --node-count 2 \
  --enable-addons monitoring \
  --generate-ssh-keys

Install kubectl (if not already installed):

az aks install-cli

Get credentials to access the cluster:

az aks get-credentials --resource-group myAKSResourceGroup --name myAKSCluster

Verify the connection:

kubectl get nodes

 What networking options are available in AKS?

A: AKS offers two primary networking models:

1. Kubenet (Basic):
   • Simple, Azure-managed networking
   • Limited features, NAT for outbound connectivity
   • Better for learning or small deployments
2. Azure CNI (Advanced):
   • Pods receive IP addresses from the VNet
   • Enables integration with existing VNets
   • Direct communication with other Azure services
   • Requires more IP address planning

For production, Azure CNI is typically recommended:

az aks create \
–resource-group myAKSResourceGroup \
–name myAKSCluster \
–network-plugin azure \
–vnet-subnet-id <subnet-id>

How do I implement high availability in AKS?

A: For production clusters, implement these HA practices:

1. Use multiple node pools with availability zones:

az aks create \
–resource-group myAKSResourceGroup \
–name myAKSCluster \
–node-count 3 \
–zones 1 2 3

Configure cluster autoscaler:

az aks update \
–resource-group myAKSResourceGroup \
–name myAKSCluster \
–enable-cluster-autoscaler \
–min-count 3 \
–max-count 10

3. Use AKS in multiple regions with Azure Traffic Manager for global HA

How do I manage the lifecycle of an AKS cluster?

AKS lifecycle management includes:

1. Upgrades:
   • Check available versions:

az aks get-upgrades –resource-group myAKSResourceGroup –name myAKSCluster

Increase number of nodes manually

az aks nodepool scale \

  –resource-group myAKSResourceGroup \

  –cluster-name myAKSCluster \

  –name <existing-nodepool-name> \

  –node-count <new-count>

Maintenance windows:

az aks maintenanceconfiguration add \
–resource-group myAKSResourceGroup \
–cluster-name myAKSCluster \
–name maintenance \
–weekday Monday \
–start-hour 1

What monitoring and observability options exist for AKS?

A: AKS provides several built-in monitoring options:

1. Container Insights (Azure Monitor):

az aks enable-addons -a monitoring -g myAKSResourceGroup -n myAKSCluster

Azure Log Analytics for log aggregation and analysis

Prometheus and Grafana via Azure Managed Grafana/Prometheus or self-hosted:

az aks enable-addons -a monitoring -g myAKSResourceGroup -n myAKSCluster \
  --enable-azure-monitor-metrics

Security Best Practices for AKS

How can I secure my AKS cluster for production use?

A: Implement these security measures:

1. Use private clusters to limit API server access:

az aks create \
–resource-group myAKSResourceGroup \
–name myAKSCluster \
–enable-private-cluster

Implement Azure AD integration for RBAC:

az aks create \
  --resource-group myAKSResourceGroup \
  --name myAKSCluster \
  --enable-aad \
  --aad-admin-group-object-ids <AAD-group-ID>

Use Azure Policy for Kubernetes:

az aks enable-addons –addons azure-policy \
–resource-group myAKSResourceGroup \
–name myAKSCluster

Enable network policies (like Calico):

az aks create \
–resource-group myAKSResourceGroup \
–name myAKSCluster \
–network-policy calico

Use Microsoft Defender for Containers:

az aks update \
–resource-group myAKSResourceGroup \
–name myAKSCluster \
–enable-defender