Lens

• Refer Here for kubernetes lens IDE

---

Statefulset

• Refer Here for official docs
• Stateful sets create multiple pods with a predicatable name in a sequential order (0 to n)
• Rolling updates will be performed in a reverse order (n-0)
• Each Pod will raise a PVC to get a PV
• Generally we will have a headless service to access specific pod
• Statefulsets are widely used to create database clusters and any application with state.
• Since we acces pod using headless service the libarary application will have a DATABASE URI changed to postgresql://user:password@booksdb-0.booksdb-svc:5432/booksdb
• Refer Here for the changes done to move away from replicaset to stateful set for database pods in library application.
• For executions watch classroom recording

---

Scheduling pods on Nodes

In Kubernetes, scheduling pods on nodes is essential to ensure resources are utilized efficiently and application requirements are met. Here are key techniques and strategies used for scheduling pods:

1. Node Selector

• The simplest way to control which nodes a pod is scheduled on.
• Specify nodeSelector in the pod specification to define node labels the pod requires.
• Only nodes with the specified labels will be considered for the pod.

yaml
spec:
nodeSelector:
disktype: ssd

2. Node Affinity and Anti-Affinity

• Node Affinity: A more flexible and expressive method than nodeSelector. Allows specifying rules for preferred and required node selection.
  • Required (hard constraint): The pod will only be scheduled if nodes match.
  • Preferred (soft constraint): The scheduler tries to match but may skip if unavailable.
• Anti-Affinity: Ensures that certain pods are not placed on the same node or close to others. Useful for high availability.

yaml
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disktype
operator: In
values:
- ssd

3. Pod Affinity and Anti-Affinity

• Controls pod placement based on the presence of other pods.
• Pod Affinity: Specifies pods that should be placed together for performance or resource-sharing needs.
• Pod Anti-Affinity: Ensures pods are spread out across nodes to prevent resource contention.

yaml
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app: frontend
topologyKey: "kubernetes.io/hostname"

4. Taints and Tolerations

• Taints: Applied to nodes to repel certain pods, setting constraints on which nodes can host which pods.
• Tolerations: Allow pods to “tolerate” taints, enabling them to be scheduled on tainted nodes.
• Useful for workloads requiring dedicated nodes or isolation.

yaml
tolerations:
- key: "example-key"
operator: "Equal"
value: "example-value"
effect: "NoSchedule"

5. Resource Requests and Limits

• Ensure nodes have the required CPU and memory resources for each pod.
• Pods with high resource requests will only be scheduled on nodes with sufficient capacity, preventing overloading.

yaml
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"

6. Priority and Preemption

• Allows higher-priority pods to preempt lower-priority ones if the cluster is under resource pressure.
• Priority classes define which pods are most important, ensuring critical applications are scheduled even in tight resource situations.

7. Topology Spread Constraints

• Enables even distribution of pods across nodes in the cluster, reducing single points of failure.
• Can control pod spread across various zones or availability domains.

yaml
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "zone"
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: frontend

8. Custom Schedulers

• Kubernetes allows using custom schedulers for unique workload requirements.
• Useful for applications needing custom placement strategies, such as data locality.

---

Administrative Activity: Upgrading K8s clusters

Self hosted

• Always go through release notes to figure out what has changed in the new version
• backup the etcd cluster and persistent volumes
• cordon the node
• drain the node
• upgrade by executing linux commands
• uncordon and make it available for scheduling

Managed k8s cluster

• Follow the cloud documentations

---

Manifests

• K8s manifests are static in nature, so every change has to be done in the file and then added to version control
• Reusability becomes a problem
• To solve this problem, we have two options
  • Kustomize
  • Helm: (Package manager for kubernetes):

---

• NextSteps:
  • ingress and ingress controller
  • Authentication and Authorization
  • Autoscaling:
    • Horizontal Pod Autoscaling
    • Vertical Pod Autoscaling
    • Node Autoscaling (Managed K8s Clusters)