Azure CLI

Private Kubernetes cluster in AKS with Azure Private Link

March 13, 2023 Azure, Azure, Azure CLI, Azure Cloud Shell, Best Practices, Cloud Computing, Cloud Native, Kubernetes, Managed Services, Microsoft, PaaS No comments

Today, we’ll take a look at a new feature in AKS called Azure Private Link, which allows you to connect to AKS securely and privately over the Microsoft Azure backbone network.

In the past, connecting to AKS from an on-premises network or other virtual network required using a public IP address, which posed potential security risks. With Azure Private Link, you can now connect to AKS over a private, dedicated connection within the Azure network, reducing the surface area for potential security threats.

How Azure Private Link works

Azure Private Link works by providing a private endpoint for your AKS cluster, which is essentially a private IP address within your virtual network. You can then configure your virtual network to allow traffic to the private endpoint, which is connected to AKS through the Azure backbone network.

When you create a private endpoint for your AKS cluster, a network interface is created in your virtual network. You can then configure your network security groups to allow traffic to the private endpoint, and create a private DNS zone to resolve the private endpoint’s DNS name.

Benefits of using Azure Private Link with AKS

Here are a few key benefits of using Azure Private Link with AKS:

Enhanced Security

Connecting to AKS over a private, dedicated connection within the Azure network can significantly reduce the surface area for potential security threats. This helps ensure that your AKS cluster is only accessible to authorized users and services.

Improved Network Performance

Azure Private Link offers fast, reliable connectivity to your AKS cluster, with low latency and high throughput. This can help improve the performance of your applications and services running on AKS.

Simplified Network Configuration

Using Azure Private Link to connect to AKS eliminates the need for complex network configurations, such as setting up VPNs or firewall rules. This can help simplify your network architecture and reduce the time and resources required for configuration and maintenance.

Getting Started with Azure Private Link for AKS

To get started with Azure Private Link for AKS, you’ll need to have an AKS cluster and a virtual network in your Azure subscription. You can then follow these high-level steps:

  1. Create a private endpoint for your AKS cluster.
  2. Configure your virtual network to allow traffic to the private endpoint.
  3. Create a private DNS zone to resolve the private endpoint’s DNS name.
  4. Connect to your AKS cluster using the private endpoint.

Here are a few examples for setting up Azure Private Link for AKS using the Azure CLI and Terraform:

Azure CLI Example

Here’s an example of how to create a private endpoint for an AKS cluster using the Azure CLI:

#Azure CLI# Set variables for resource names and IDs
AKS_RESOURCE_GROUP=myAKSResourceGroup
AKS_CLUSTER_NAME=myAKSCluster
VNET_NAME=myVirtualNetwork
SUBNET_NAME=mySubnet
PRIVATE_DNS_ZONE_NAME=myPrivateDNSZone
PRIVATE_ENDPOINT_NAME=myAKSPrivateEndpoint
PRIVATE_ENDPOINT_GROUP_NAME=myAKSPrivateEndpointGroup

# Create a private endpoint for the AKS cluster
az network private-endpoint create \
  --name $PRIVATE_ENDPOINT_NAME \
  --resource-group $AKS_RESOURCE_GROUP \
  --vnet-name $VNET_NAME \
  --subnet $SUBNET_NAME \
  --private-connection-resource-id "/subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.ContainerService/managedClusters/{aks-cluster-name}" \
  --group-id $PRIVATE_ENDPOINT_GROUP_NAME \
  --connection-name $PRIVATE_ENDPOINT_NAME-conn \
  --location northeurope \
  --dns-name $PRIVATE_DNS_ZONE_NAME.privatelink.azure.com
In this example, we're creating a private endpoint for an AKS cluster named "myAKSCluster" in a virtual network named "myVirtualNetwork". We're also creating a private DNS zone named "myPrivateDNSZone" and specifying a connection name of "myAKSPrivateEndpoint-conn".

Terraform Example

Here’s an example of how to create a private endpoint for an AKS cluster using Terraform:

#hcl-terraform# Set variables for resource names and IDs
variable "resource_group_name" {}
variable "aks_cluster_name" {}
variable "virtual_network_name" {}
variable "subnet_name" {}
variable "private_dns_zone_name" {}
variable "private_endpoint_name" {}
variable "private_endpoint_group_name" {}

# Create a private endpoint for the AKS cluster
resource "azurerm_network_private_endpoint" "aks_endpoint" {
  name                = var.private_endpoint_name
  location            = "eastus"
  resource_group_name = var.resource_group_name
  subnet_id           = azurerm_subnet.aks.id

  private_service_connection {
    name                          = "${var.private_endpoint_name}-conn"
    private_connection_resource_id = "/subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.ContainerService/managedClusters/${var.aks_cluster_name}"
    group_ids                     = [var.private_endpoint_group_name]
  }

  custom_dns_config {
    fqdn            = "${var.private_dns_zone_name}.privatelink.azure.com"
    ip_addresses    = azurerm_private_endpoint_dns_zone_group.aks_dns_zone_group.ip_addresses
    private_zone_id = azurerm_private_dns_zone.aks_dns_zone.id
  }
}
In this example, we're creating a private endpoint for an AKS cluster named "myAKSCluster" in a virtual network named "myVirtualNetwork". We're also creating a private DNS zone named "myPrivateDNSZone" and specifying a connection name of "myAKSPrivateEndpoint-conn".

Detailed instructions for setting up Azure Private Link for AKS can be found in the Microsoft Azure documentation.

In Summary: Azure Private Link is a powerful new feature in AKS that allows you to connect to your AKS cluster securely and privately over the Azure backbone network. By reducing the surface area for potential security threats and improving network performance, Azure Private Link can help ensure that your AKS workloads are secure, performant, and easy to manage. If you haven’t yet tried out Azure Private Link with AKS, now is a great time to get started!

Azure Cosmos DB–Multi Master

October 8, 2018 .NET, .NET Core, .NET Framework, ASP.NET, Azure, Azure CLI, Azure Cosmos DB, CosmosDB, Data Consistancy, Data Integrity, Microsoft, Multi-master, Performance, Reliability, Resilliancy, Scalability, Scale Up No comments

During the Ignite 2018, Microsoft has announced the general availability of Multi-Master feature being introduced to Azure Cosmos DB to provide more control into data redundancy and elastic scalability for your data from different regions with multiple writes and read instances.

What is Multi-Master essentially?

Multi-master is a capability that provided as part of Cosmos DB, that would provide you multiple write regions and provides an option to handle conflict resolution automatically through different options provided by the platform. Most of the major scenarios you would encounter the conflict can be resolved with these simple configurations.

A sample diagram depicting a use case of load balanced web app writing to respective regional master:-

image

With multi-master, Azure Cosmos DB delivers a single digit millisecond write latency at the 99th percentile anywhere in the world, and now offers 99.999 percent write availability (in addition to 99.999 percent read availability) backed by the industry-leading SLAs.

image

Wow! That’s an amazing performance Cosmos DB guarantees to provide so that your mission-critical systems will have zero downtime, if they start using Cosmos DB.

 

How to Enabled Multi-Master support in your Cosmos DB solutions?

Currently multi-master can only be enabled for new Cosmos DB instances using “Enable Multi-Master” option in Azure Portal or through PowerShell or ARM templates or through SDK.

These options are detailed below with necessary examples:

1.) Azure Portal – Enable Multi-region writes and Enable geo-redundancy

image

2.) Azure CLI 
Set the “enable-multiple-write-locations” parameter to “true”

az cosmosdb create \
   –-name "thingx-cosmosdb-dev" \
   --resource-group "consmosify-dev" \
   --default-consistency-level "Session" \
   --enable-automatic-failover "true" \
   --locations "EastUS=0" "WestUS=1" \
   --enable-multiple-write-locations true \

3.) AzureRM PowerShell
In AzureRM PowerShell cmdlet – Set enableMultipleWriteLocations parameter to “true”

$locations = @(@{"locationName"="East US"; "failoverPriority"=0},
             @{"locationName"="West US"; "failoverPriority"=1})

$iprangefilter = ""

$consistencyPolicy = @{"defaultConsistencyLevel"="Session";
                       "maxIntervalInSeconds"= "10";
                       "maxStalenessPrefix"="200"}

$CosmosDBProperties = @{"databaseAccountOfferType"="Standard";
                        "locations"=$locations;
                        "consistencyPolicy"=$consistencyPolicy;
                        "ipRangeFilter"=$iprangefilter;
                        "enableMultipleWriteLocations"="true"}

New-AzureRmResource -ResourceType "Microsoft.DocumentDb/databaseAccounts" `
  -ApiVersion "2015-04-08" `
  -ResourceGroupName "consmosify-dev" `
  -Location "East US" `
  -Name "thingx-cosmosdb-dev" `
  -Properties $CosmosDBProperties

4.) Through CosmosDB SDK
Setting connection policy in DocumentDBClient and set UseMultipleWriteLocations to true.

ConnectionPolicy policy = new ConnectionPolicy
{
   ConnectionMode = ConnectionMode.Direct,
   ConnectionProtocol = Protocol.Tcp,
   UseMultipleWriteLocations = true,
};
policy.PreferredLocations.Add("East US");
policy.PreferredLocations.Add("West US");
policy.PreferredLocations.Add("West Europe");
policy.PreferredLocations.Add("North Europe");
policy.PreferredLocations.Add("Southeast Asia");
policy.PreferredLocations.Add("Japan East");
policy.PreferredLocations.Add("Japan West");

Azure Cosmos DB multi-master configuration is the game changes that really makes it a true global scale database with automatic conflict resolution capabilities for data synchronization and consistancy.

In my later sessions I will write examples to cover how conflict resolutions can be configured and used in realtime scenarios.

Useful Refs:

Getting Started with Azure CLI 2.0

September 30, 2018 Azure, Azure CLI, Azure Cloud Shell, AzureRM.PowerShell, PowerShell No comments

Older days we used to manage azure resources through AzureRM PowerShell modules . This was very much flexible for any Azure Administrator or Developers to run Automated Deployments to Azure Resource Manager resources.

Azure CLI  is the next improved version with simplified cmdlets to make life easier and it is cross-platform.

You can use Azure CLI in two ways:

  1. Azure Portal – Through Azure Cloud Shell
  2. PowerShell module

Installation Steps:

  • Download Azure CLI designed for Linux/Windows/MacOS based on your OS.
  • Install image and follow the steps.

 

image

image

  • Verify the Installation by executing cmdlet [  az –version  ]

az –-version

image

Running the Azure CLI from PowerShell has some advantages over running the Azure CLI from the Windows command prompt, provides additional tab completion features.

Now let us try logging in to Azure using Azure CLI. There are various ways of logging in, for this article I would try simple web login using az login command.

Execute the following cmdlet to login to Azure:

az login

The Azure CLI will  launch your default browser to open the Azure sign-in page. After a successful sign in, you’ll be connected to your Azure subscription.  If it fails, follow the command-line instructions and enter an authorization code at https://aka.ms/devicelogin.

Create a azure resource group and verify:

az group create –name "thingx-dev" –location "southcentralus" 
az group list --output table

 

Hope that is helpful for you to get started with Azure CLI. To learn more about Azure CLI cmdlets : https://github.com/Azure/azure-cli