Azure Kubernetes Solutions

The Azure built-in roles Resource Policy Contributor and Owner have these operations.

There are two ways to manage AKS to Azure access through Azure Active Directory (Azure AD): service principals or managed identities for Azure resources

There are two ways to manage AKS to Azure access through Azure Active Directory (Azure AD): service principals or managed identities for Azure resources.

The cluster identity is used by the AKS control plane components to manage cluster resources including ingress load balancers, AKS managed public IPs, etc.

The kubelet identity is used to authenticate with Azure Container Registry (ACR). Some add-ons also support authentication using a managed identity.

Outside-in access.

Inside-out access.

Use the Nodes and Controllers views to view the health and performance of the pods that are running on nodes and controllers, and their resource consumption in terms of CPU and memory.

You can use Metrics Explorer to view the Inflight Requests counter

Services logically group pods to allow for direct access on a specific port via an IP address or DNS name. ServiceTypes allow you to specify what kind of Service you want. You can distribute traffic using a load balancer. More complex routing of application traffic can also be achieved with ingress controllers.

ClusterIP creates an internal IP address for use within the AKS cluster. This Service is good for internal-only applications that support other workloads within the cluster.

Nodes receive an IP address from the Azure virtual network subnet. Pods receive an IP address from a logically different address space than the nodes' Azure virtual network subnet. Network address translation (NAT) is then configured so that the pods can reach resources on the Azure virtual network. The source IP address of the traffic is translated to the node's primary IP address.

You can let the Azure platform create and configure the virtual networks for you, or choose to deploy your AKS cluster into an existing virtual network subnet.

With Azure CNI, every pod gets an IP address from the subnet and can be accessed directly

The LoadBalancer only works at layer 4. At layer 4, the Service is unaware of the actual applications, and can't make any more routing considerations.

Ingress controllers work at layer 7 and can use more intelligent rules to distribute application traffic.

The nodes, also called agent nodes or worker nodes

AKS groups nodes of the same configuration into node pools of VMs that run AKS workloads

If you want to have only one node pool in your AKS cluster, for example in a development environment, you can schedule application pods on the system node pool.

Pods typically have a 1:1 mapping with a container. In advanced scenarios, a pod may contain multiple containers. Multi-container pods are scheduled together on the same node, and allow containers to share related resources.

When you create a pod, you can define resource requests to request a certain amount of CPU or memory resources. The Kubernetes Scheduler tries to meet the request by scheduling the pods to run on a node with available resources.

maximum resource limits

Pods are typically ephemeral, disposable resources.

The computers in a cluster that run the tasks are called nodes, and the computers that run the scheduling software are called control planes.

Commands from the master node are sent to the kubelet on the worker nodes.

The kube-controller-manager takes the YAML file and tasks the kube-scheduler with deciding which worker nodes the app or workload should run based on predetermined constraints.

If one or more pods happen to fail, the ReplicaSet replaces them. In this way, Kubernetes is said to be self-healing.

Kubernetes supports rollbacks, rolling updates, and pausing rollouts. Additionally, deployments use ReplicaSets in the background to ensure that the specified number of identically configured pods are running.