An AKS cluster can be launched in its own VPC (basic networking configuration) or in an existing VPC (advanced networking configuration); both can be launched via Azure CLI. There are a set of arguments that we can specify during cluster creation, which include the following:

In the following example, we'll first create a cluster with two nodes and enable addons for monitoring to enable Azure monitor for the cluster, and http_application_routing to enable HTTP application routing for ingress:

// create an AKS cluster with two nodes
# az aks create --resource-group devops --name myAKS --node-count 2 --enable-addons monitoring,http_application_routing --generate-ssh-keys
Running...
# az aks list --resource-group devops
[
 {  
  "aadProfile":null,
  "addonProfiles":{  
    "httpApplicationRouting":{  
      "config":{  
        "HTTPApplicationRoutingZoneName":"cef42743fd964970b357.centralus.aksapp.io"
      },
      "enabled":true
    },
    "omsagent":{  
      "config":{  
        "logAnalyticsWorkspaceResourceID":...
      },
      "enabled":true
    }
  },
  "agentPoolProfiles":[  
    {  
      "count":2,
      "maxPods":110,
      "name":"nodepool1",
      "osDiskSizeGb":30,
      "osType":"Linux",
      "storageProfile":"ManagedDisks",
      "vmSize":"Standard_DS2_v2"
    }
  ],
  "dnsPrefix":"myAKS-devops-f82579",
  "enableRbac":true,
  "fqdn":"myaks-devops-f82579-077667ba.hcp.centralus.azmk8s.io",
  "id":"/subscriptions/f825790b-ac24-47a3-89b8-9b4b3974f0d5/resourcegroups/devops/providers/Microsoft.ContainerService/managedClusters/myAKS",
  "kubernetesVersion":"1.9.11",
  "linuxProfile":{  
    "adminUsername":"azureuser",
    "ssh":{  
      "publicKeys":[  
        {  
          "keyData":"ssh-rsa xxx"
        }
      ]
    }
  },
  "location":"centralus",
  "name":"myAKS",
  "networkProfile":{  
    "dnsServiceIp":"10.0.0.10",
    "dockerBridgeCidr":"172.17.0.1/16",
    "networkPlugin":"kubenet",
    "networkPolicy":null,
    "podCidr":"10.244.0.0/16",
    "serviceCidr":"10.0.0.0/16"
  },
  "nodeResourceGroup":"MC_devops_myAKS_centralus",
  "provisioningState":"Succeeded",
  "resourceGroup":"devops",
  "servicePrincipalProfile":{  
    "clientId":"db016e5d-b3e5-4e22-a844-1dad5d16fec1"
  },
  "type":"Microsoft.ContainerService/ManagedClusters"
}
]

After the cluster is launched, we can use the get-credentials subcommand to configure our kubeconfig. The context name will be the cluster name, which in this case is myAKS:

// configure local kubeconfig to access the cluster
# az aks get-credentials --resource-group devops --name myAKS
Merged "myAKS" as current context in /home/chloe/.kube/config

// check current context
# kubectl config current-context
myAKS

Let's see whether the nodes have joined the cluster. Make sure that all of the nodes are in the Ready state:

# kubectl get nodes
NAME STATUS ROLES AGE VERSION
aks-nodepool1-37748545-0 Ready agent 12m v1.9.11
aks-nodepool1-37748545-1 Ready agent 12m v1.9.11

Let's try to deploy a ReplicaSet via the example we used in Chapter3:

# kubectl create -f chapter3/3-2-3_Service/3-2-3_rs1.yaml
replicaset.apps/nginx-1.12 created

Create a service to access the ReplicaSet. We will use the chapter3/3-2-3_Service/3-2-3_service.yaml file and add the type: LoadBalancer line in the spec:

kind: Service
apiVersion: v1
metadata:
  name: nginx-service
spec:
  selector:
    project: chapter3
    service: web
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      name: http

We can then watch the service until the EXTERNAL-IP changes to an external IP address. Here, we get 40.122.78.184:

// watch the external ip from <pending> to IP
# kubectl get svc --watch
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 6h
nginx-service LoadBalancer 10.0.139.13 40.122.78.184 80:31011/TCP 1m

Let's visit the site!

In the preceding example, we have demonstrated how to deploy an nginx service to AKS and use its load balancer. How about if we already have a set of resources in an existing VNet, and we want to launch an AKS cluster inside the VNet to communicate with existing resources? Then, we need to use advanced networking in AKS. The fundamental difference between basic and advanced networking is that basic networking uses kubenet (https://github.com/vplauzon/aks/tree/master/aks-kubenet) as a network plugin, while advanced networking uses the Azure CNI plugin (https://github.com/Azure/azure-container-networking/tree/master/cni). Compared to basic networking, advanced networking has more limitations. For example, the default maximum number of pods on a node is 30, instead of 110. This is because only 30 additional IP addresses are configured by Azure CNI for the NIC on a node. The pod IPs are the secondary IPs on the NICs, so the private IPs are assigned the pods that are accessible inside the virtual network. When using kubenet, the cluster IPs are assigned to the pods, which don't belong to the virtual network but are instead managed by AKS. The cluster IPs won't be accessible outside of the cluster. Unless you have special requirements, such as if you want to gain access to the pods from outside the cluster or you want connectivity between existing resources and the cluster, the basic networking configuration should be able to fulfill most scenarios. 

Let's see how we can create an AKS cluster with advanced networking. We need to specify the existing subnet for the cluster. First, let's list the subnet IDs in the VNet devops-vnet file that we created earlier:

# az network vnet subnet list --vnet-name devops-vnet --resource-group devops | jq .[].id
"/subscriptions/f825790b-ac24-47a3-89b8-9b4b3974f0d5/resourceGroups/devops/providers/Microsoft.Network/virtualNetworks/devops-vnet/subnets/default"
"/subscriptions/f825790b-ac24-47a3-89b8-9b4b3974f0d5/resourceGroups/devops/providers/Microsoft.Network/virtualNetworks/devops-vnet/subnets/test"

Let's use the default subnet. Note that one subnet should only locate one AKS cluster in advanced networking. Also, the service CIDR we specified, which is used to assign cluster IPs, cannot overlap the subnet CIDR in which the cluster is located:

# az aks create --resource-group devops --name myAdvAKS --network-plugin azure --vnet-subnet-id /subscriptions/f825790b-ac24-47a3-89b8-9b4b3974f0d5/resourceGroups/devops/providers/Microsoft.Network/virtualNetworks/devops-vnet/subnets/default --service-cidr 10.2.0.0/24 --node-count 1 --enable-addons monitoring,http_application_routing --generate-ssh-keys
 - Running ..
{
  "aadProfile": null,
  "addonProfiles": {
      "httpApplicationRouting": {
        "config": {
          "HTTPApplicationRoutingZoneName": "cef42743fd964970b357.centralus.aksapp.io"
        },
        "enabled": true
      },
      "omsagent": {
        "config": {
          "logAnalyticsWorkspaceResourceID":
        },
        "enabled": true
      }
   },
  "agentPoolProfiles": [
    {
      "count": 1,
      "maxPods": 30,
      "name": "nodepool1",
...
      "vmSize": "Standard_DS2_v2"
    }
  ],
  "dnsPrefix": "myAdvAKS-devops-f82579",
  "enableRbac": true,
  "fqdn": "myadveks-devops-f82579-059d5b24.hcp.centralus.azmk8s.io",
  "id": "/subscriptions/f825790b-ac24-47a3-89b8-9b4b3974f0d5/resourcegroups/devops/providers/Microsoft.ContainerService/managedClusters/myAdvAKS",
  "kubernetesVersion": "1.9.11",
  "linuxProfile": {
    "adminUsername": "azureuser",
    "ssh": {
      "publicKeys": [
        ...
      ]
    }
  },
  "location": "centralus",
  "name": "myAdvAKS",
  "networkProfile": {
    "dnsServiceIp": "10.0.0.10",
    "dockerBridgeCidr": "172.17.0.1/16",
    "networkPlugin": "azure",
    "networkPolicy": null,
    "podCidr": null,
    "serviceCidr": "10.2.0.0/24"
  },
  "nodeResourceGroup": "MC_devops_myAdvAKS_centralus",
  "provisioningState": "Succeeded",
  "resourceGroup": "devops",
  "servicePrincipalProfile": {
    "clientId": "db016e5d-b3e5-4e22-a844-1dad5d16fec1",
    "secret": null
  },
  "tags": null,
  "type": "Microsoft.ContainerService/ManagedClusters"
}

Remember to configure kubeconfig:

# az aks get-credentials --resource-group devops --name myAdvAKS
Merged "myAdvAKS" as current context in /home/chloe/.kube/config

If we repeat the preceding code for chapter3/3-2-3_Service/3-2-3_rs1.yaml and chapter3/3-2-3_Service/3-2-3_service.yaml, we should be able to achieve the same result.