04. Node Selectors¶

Node Selector¶

nodeSelector is the simplest recommended form of node selection constraint.

Node Labels¶

Like many other Kubernetes objects, nodes have labels. You can attach labels manually. Kubernetes also populates a standard set of labels on all nodes in a cluster.

Node Affinity¶

Node affinity is conceptually similar to nodeSelector, allowing you to constrain which nodes your Pod can be scheduled on based on node labels.

More precisely "Node Affinity" the more complete than "Node Selector". It gets more filters and conditions to you.

Node Affinity Type¶

Available¶

required DuringScheduling Ignored DuringExecution: The scheduler can't schedule the Pod unless the rule is met. This functions like nodeSelector, but with a more expressive syntax.
preferred DuringScheduling Ignored DuringExecution: The scheduler tries to find a node that meets the rule. If a matching node is not available, the scheduler still schedules the Pod.

Planned¶

available in future version

	DuringScheduling	DuringExecution
Type 1	Required	Ignore
Type 1	Preferred	Ignore
Type 1	Required	Required

Node Affinity + Taint/Tolerance¶

The only way that you assign specific pods to specific node, is a combine "Node Affinity" + "Taint/Tolerance"

Resource Management for Pods and Containers¶

Resource requests and limits of Pod and container¶

For each container, you can specify resource limits and requests, including the following:

    spec.containers[].resources.limits.cpu
    spec.containers[].resources.limits.memory
    spec.containers[].resources.limits.hugepages-<size>
    spec.containers[].resources.requests.cpu
    spec.containers[].resources.requests.memory
    spec.containers[].resources.requests.hugepages-<size>

Resource units in Kubernetes¶

CPU resource units
Fractional values
0.5 equal 500m
each core divides to 1000
minimum cpu unit is 1m
5200m core = 4 core full + 200m from one other core
Memory resource units

Note: Default resource unit for each container is 1 core cpu and 512 Mi memory

Container resources¶

An example

---
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

DaemonSet¶

A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. Exactly one instance of every pod.

Static Pods¶

Static Pods are managed directly by the kubelet daemon on a specific node, without the API server observing them.

Have a quick review of kubelet workload
Have a quick review of schedular workload
Have a quick review of controller workload

Configure Multiple Schedulers¶

Multiple Schedulers

Monitoring¶

Metric Server¶

Metrics Server is a scalable, efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines.

kubectl top nodes

Logging¶

Kubernetes Embed Log Features¶

kubectl logs -f <resource-name>
kubectl -n kube-system get events
 ```

#### Autoscaling Workloads

In Kubernetes, you can [scale] a workload depending on the current demand of resources. This allows your cluster to react to changes in resource demand more elastically and efficiently.

- [HorizontalPodAutoscaler]
- [VerticalPodAutoscaler]

### [Debugging]

[**cAdvisor**]: Daemon for collecting, aggregating and exposing container metrics included in Kubelet.

- kubernetes can expose logs via event
- kubernetes shows container logs, if you have more than one container you should enter container name

## Application Lifecycle Management

Application [Lifecycle] Management

- Rolling Update, Rolling Back
- Configure Applications
  - Configuring Command and Arguments in Application
  - Configure Environment Variables
  - Configure ConfigMap and Secret

- Multi Container PODs
  - Multi Container PODs and POD Design-Pattern
  - InitContainer

- Self Healing Application

### Rolling Update

The key feature for "Deployment" to update and rollout pods

**Annotation**: If we want to have history from our updates we should use key "**kubernetes.io/change-cause**" from **annotations**

```bash
kubectl annotate deployments <deployment-name> kubernetes.io/change-cause="change message"
kubectl rollout history deployments <deployment-name>

Service Mesh¶

In software architecture, a service mesh is a dedicated infrastructure layer for facilitating service-to-service communications between services or microservices, using a proxy

What does a Service mesh do?¶

A service mesh essentially manages the traffic flow between multiple microservices primarily using a sidecar proxy.

What are the Best Service Mesh Tools?¶

GitOps¶

Traditional tools like Jenkins, GitLab couldn't follow the state of code. So we need to new tools that can follow changes over code and compares it to running state.

ArgoCD and FluxCD is the populated tools for this.