AKS From Zero To Hero - Part 2

Welcome to the second post in a series of "AKS From Zero To Hero".
In the first post, we talked about K8s in general, manifest file, Cluster Nodes, etc. In this post, we will continue the discussion around K8S and AKS.

In this post, I will try to simplify K8S components, and services.

Pods are the smallest unit that can be deployed in Kubernetes, it consist of one or more containers that are always scheduled together, each pod is given a unique IP addres, hence  containers in a pod can speak to each other via localhost. Pods typically contain only a single container

Note: K8s is not responsible to create images, therefore the images should be created outside the K8S cluster in order to use it in your pod!, at the same time pod are immutabe, so if the pod died K8s will create a new one.

Deployment: provides declarative updates for Pods and ReplicaSets, it allow you to easily scale and perform rolling upgrades

you can easily, scale up or down by changing this attribute in yaml file or via K8S CLI:

this will create 5 pods:
spec:
  replicas: 5
And to scale down you can just change it to:
spec:
  replicas: 2

Using CLI:
kubectl scale --replicas=5 deployment/azure-vote-front   # scale up
kubectl scale --replicas=2 deployment/azure-vote-front   # scale down

Note: there are multible deployment-strategies, such as Recreate, RollingUpdate,etc.. -- read more.

Services:  is a logical abstraction for a deployed group of pods in a cluster (which all perform the same function). Since pods are ephemeral, a service enables a group of pods, which provide specific functions (web services, image processing, etc.) to be assigned a name and unique IP address, so define a DNS entry that can be used to refer to a group of pods

there are three type of services: nodePort, clusterIP, loadbalancer, I will explain them all in AKS part 3

Ingress:  it define how traffic outside the cluster is routed to inside the cluster, it used to expose Kubernetes services to the world and route traffic to internal services based on factors such as host and path

Note: Ingress is L7

ConfigMaps: is an API object that lets you store configuration for other objects to use. Unlike most Kubernetes objects that have a spec , a ConfigMap has data and binaryData fields. These fields accept key-value pairs as their values. Both the data field and the binaryData are optional

so, simple you can use it to bypass variable to your containers

kind: ConfigMap
apiVersion: v1
metadata:
  name: example-configmap
data:
  database: mongodb
  database_uri: mongodb://localhost:27017
    keys: |
    image.public.key=771
    rsa.public.key=42

Secrets: are similar to ConfigMaps but are specifically intended to hold confidential data. secrets are secure objects which store sensitive data, such as passwords, OAuth tokens, and SSH keys, etc. with encryption in your clusters. Using Secrets gives you more flexibility in a Pod Life cycle definition and control over how sensitive data is used

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

StatefulSet: workload API object used to manage stateful applications. Manages the deployment and scaling of a set of Pods, and provides guarantees about the ordering and uniqueness of these Pods. Like a Deployment, a StatefulSet manages Pods that are based on an identical container spec

so, it basically sync the data between the pods, you can use it with SQL, MySQL, MongoDB, etc. but why, as we said before pods are ephemeral, so if the pod died and contains data even if you are using volumes still it's not enough when we talk about data stored in a table inside the database, hence WE NEED THE DATA TO BE SYNCED BETWEEN ALL PODS and the only way to achieve that by using statefulset.

DaemonSet: A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a DaemonSet will clean up the Pods it created

Volumes: volume is a directory that contains data accessible to containers in a given Pod in the orchestration and scheduling platform. Volumes provide a plug-in mechanism to connect ephemeral containers with persistent data stores elsewhere

Kubernetes supports more than 20 types of volumes. A local volume can represent mounted local storage devices such as partitions, directories or disks

What's next?
This was part two of the article. In the next part, we will continue this discussion with AKS.
Continue Reading: AKS From Zero To Hero - Part 3