The document provides an introduction to microservices and Kubernetes (K8s), explaining concepts like service-oriented architecture, pods, deployments, and various configuration methods. It details Kubernetes' architecture, including control planes, nodes, networking options, and storage solutions, including Azure's specific implementations. Additionally, it discusses scaling options and the benefits and challenges of a microservices architecture.

1. A quick introduction to AKS
Alessandro Melchiori - @amelchiori
CodicePlastico

3. What happens after you die?

4. What is life?

5. What is a microservice?

7. What are microservices
service - oriented architecture
composed of loosely coupled elements
that have bounded context
Adrian Cockcroft
“
”

8. What are microservices
service - oriented architecture
composed of loosely coupled elements
that have bounded context
Adrian Cockcroft
“
”
Services talk with each other over the network

9. What are microservices
service - oriented architecture
composed of loosely coupled elements
that have bounded context
Adrian Cockcroft
“
”
You can update the services
independently;
updating one service doesn’t require
changing any other service

10. What are microservices
service - oriented architecture
composed of loosely coupled elements
that have bounded context
Adrian Cockcroft
“
”Self-contained; you can update the code without knowing
anything about the internals of other microservices

11. Kubernetes 101

12. Kubernetes
Greek for “Helmsman” < the person who steers a ship

13. Kubernetes
Greek for “Helmsman” < the person who steers a ship

14. K8s
Greek for “Helmsman” < the person who steers a ship

15. ● Born in Google
● Donated to CNCF in 2014
● Open source (Apache 2.0)
● v1.0 July 2015
● Written in Go/Golang
● Code is on GitHub (where otherwise?)
K8s: some infos

16. Kubernetes is a cluster technology.
It means that you will see a cluster of computers
as one entity. You will not deploy an application
on a specific computer, but somewhere in the
cluster
What’s Kubernetes (k8s)

17. K8s 101 - Nodes
Each computer in the cluster is called a node.
Eventually, the nodes will host your applications.
The nodes can be spread throughout the world in
different data centers

18. K8s 101 - Pods
Pods are the smallest unit you will eventually
deploy to the cluster.
A single Pod can hold multiple containers.

19. K8s 101 - Deployments
Deployments are requirements you give to
Kubernetes regarding your applications (Pods)

20. K8s 101 - Services
Services are an abstract way to expose an
application running on a set of Pods as a
network service.

21. Declarative model
& Desired state

22. Management techniques
The kubectl command-line tool supports several different ways to create and manage
Kubernetes objects:
● Imperative commands
● Imperative object configuration
● Declarative object configuration

23. Imperative commands
The simplest way to get started or to run a one-off task in a cluster.
kubectl run nginx --image nginx

24. Imperative commands
PRO:
● Commands are simple, easy to learn
and easy to remember.
● Commands require only a single step
to make changes to the cluster
CONS:
● Commands do not integrate with change
review processes.
● Commands do not provide an audit trail
associated with changes.

25. Imperative object configuration
In imperative object configuration, the kubectl command specifies the operation
(create, replace, etc.), optional flags and at least one file name.
The file specified must contain a full definition of the object in YAML or JSON format.
kubectl create -f nginx.yaml

26. Imperative object configuration
PRO:
● Object configuration can be stored in
a source control system such as Git
(vs. imperative commands)
● It’s simpler and easier to understand
(vs. declarative object configuration)
CONS:
● Object configuration requires basic
understanding of the object schema
(vs. imparative commands)
● It works best on files, not directories
(vs. declarative object configuration)
● Updates to live objects must be reflected
in configuration files, or they will be lost
during the next replacement
(vs. declarative object configuration)

27. Declarative object configuration
Using declarative object configuration, a user operates on object configuration files stored
locally, however the user does not define the operations to be taken on the files.
Create, update, and delete operations are automatically detected per-object by kubectl.
kubectl apply -f configs/

28. Declarative object configuration
PRO:
● Changes made directly to live objects
are retained, even if they are not merged
back into the configuration files
● It has better support for operating
on directories and automatically
detecting operation types per-object
CONS:
● Declarative object configuration is harder
to debug

29. DEMO

30. K8s + Azure = AKS

31. Kubernetes cluster architecture
A Kubernetes cluster is divided into two components:

32. Kubernetes cluster architecture
A Kubernetes cluster is divided into two components:
Control plane nodes provide the core Kubernetes
services and orchestration of application
workloads

33. Kubernetes cluster architecture
A Kubernetes cluster is divided into two components: Nodes run your application workloads.

34. Control plane
When you create an AKS cluster, a control plane
is automatically created and configured.
This control plane is provided as a managed
Azure resource abstracted from the user.
There's no cost for the control plane, only the
nodes that are part of the AKS cluster.

35. Nodes and node pools
To run your applications and
supporting services, you need a
Kubernetes node.
An AKS cluster has one or more nodes,
which is an Azure virtual machine (VM)
that runs the Kubernetes node
components and container runtime

36. Nodes resource reservation
Node resources are utilized by AKS to make the
node function as part of your cluster.
This can create a discrepancy between your
node's total resources and the resources
allocatable when used in AKS.
Don’t Forget!

37. Node pools
Nodes of the same configuration are grouped together into
node pools.
A Kubernetes cluster contains one or more node pools
When you scale or upgrade an AKS cluster, the action is
performed against the default node pool.
You can also choose to scale or upgrade a specific node
pool.

38. AKS Networking

39. AKS networking
To allow access to your applications, or for application components to communicate with each
other, Kubernetes provides an abstraction layer to virtual networking. Kubernetes nodes are
connected to a virtual network, and can provide inbound and outbound connectivity for pods.
The kube-proxy component runs on each node to provide these network features.
To simplify the network configuration for application workloads, Kubernetes uses Services
to logically group a set of pods together and provide network connectivity.

40. AKS networking: Cluster IP
Creates an internal IP address for use within the AKS cluster.
Good for internal-only applications that support other workloads within the cluster.

41. AKS networking: NodePort
Creates a port mapping on the underlying node that allows the application to be accessed
directly with the node IP address and port.

42. AKS networking: Load balancer
Creates an Azure load balancer resource, configures an external IP address, and connects the
requested pods to the load balancer backend pool.

43. AKS networking: ingress controller
The LoadBalancer only works at layer 4 - the Service is unaware of the actual applications,
and can't make any additional routing considerations. Ingress controllers work at layer 7,
and can use more intelligent rules to distribute application traffic.

44. Azure Virtual Networks
In AKS, you can deploy a cluster that uses one of the following two network models:
● Kubenet networking - The network resources are typically created and configured
as the AKS cluster is deployed.
● Azure Container Networking Interface (CNI) networking - The AKS cluster is connected
to existing virtual network resources and configurations.

45. AKS Storage

46. Storage options for AKS applications
The core concepts that provide storage
to your applications in AKS are:
● Volumes
● Persistent volumes
● Storage classes
● Persistent volume claims

47. AKS storage options
A volume represents a way to store, retrieve, and persist data across pods and through
the application lifecycle. Volumes that are defined and created as part of the pod lifecycle
only exist until the pod is deleted.
You can manually create these data volumes to be assigned to pods directly,
or have Kubernetes automatically create them.

48. AKS storage options
Traditional volumes to store and retrieve data are created as Kubernetes resources backed by
Azure Storage. These data volumes can use Azure Disks or Azure Files:
- Azure Disks can be used to create a Kubernetes DataDisk resource.
Azure Disks are mounted as ReadWriteOnce, so are only available to a single pod. For
storage volumes that can be accessed by multiple pods simultaneously, use Azure Files.
- Azure Files can be used to mount an SMB 3.0 share backed by an Azure Storage account
to pods. Files let you share data across multiple nodes and pods.

49. AKS storage options

50. AKS Scaling

51. Manually scale pods or nodes
kubectl scale --replicas=5 deployment/azure-vote-front
az aks scale `
--resource-group myResourceGroup `
--name myAKSCluster `
--node-count 3

52. Autoscale pods: HPA
Kubernetes uses the horizontal pod
autoscaler (HPA) to monitor the resource
demand and automatically scale
the number of replicas.
When you configure the horizontal pod
autoscaler, you define the minimum and
maximum number of replicas that can run.
You also define the metric to monitor and
base any scaling decisions on.

53. Cluster autoscaler
To respond to changing pod demands,
Kubernetes has a cluster autoscaler,
that adjusts the number of nodes based
on the requested compute resources
in the node pool.
Cluster autoscaler is typically used alongside
the horizontal pod autoscaler.

54. ACI integration
Virtual nodes are deployed to an additional subnet in the same virtual network as your AKS cluster.
This virtual network configuration allows the traffic between ACI and AKS to be secured.

55. Kubernetes event-driven autoscale (KEDA)
KEDA is a single-purpose and lightweight
component that can be added into any
Kubernetes cluster.
KEDA works alongside standard Kubernetes
components like the horizontal pod autoscaler
and can extend functionality without
overwriting or duplication.

57. Microservice architecture
THE “GOOD”
● An application is sum of its components
● Better fault isolation
● Components can be spread across
multiple servers
THE “BAD”
● Many components, many moving parts
● Difficult to manage inter-communication
● Manual management can be difficult

58. ALESSANDRO MELCHIORI
Founder & Software developer @CodicePlastico
alessandro@codiceplastico.com
@amelchiori

59. Grazie!