diff --git a/Content/20240215121050-kubernetes.org b/Content/20240215121050-kubernetes.org index 5d4e5f7..9d1f5cd 100644 --- a/Content/20240215121050-kubernetes.org +++ b/Content/20240215121050-kubernetes.org @@ -8,6 +8,10 @@ see [[id:f822f8f6-89eb-4aa8-ac8f-fdcff3f06fb9][Orchestration]] * Stream +** 0x22E3 + - reading up on [[id:7cb8489b-2b84-4224-b3f9-9f5bf0f38cfe][autoscaling]] + - see [[id:7f960631-c727-41b8-80c2-3ccaa4ae4ba2][Scheduling Algorithms]] & [[id:59305648-ed10-4298-be07-cd67f277f612][Scheduling-K8S]] + ** 0x22E2 - reading https://sookocheff.com/post/kubernetes/understanding-kubernetes-networking-model/ - reading up on [[id:2244b835-3c8a-496e-b4bd-5ab0951c7d29][ConfigMap]]s diff --git a/Content/20240501195739-scheduling_algorithms.org b/Content/20240501195739-scheduling_algorithms.org index 4554c83..16c181d 100644 --- a/Content/20240501195739-scheduling_algorithms.org +++ b/Content/20240501195739-scheduling_algorithms.org @@ -21,6 +21,9 @@ In practice, these goals often conflict. Incorporating multiple dimensions when modelling the priority functions is a difficult (and interesting) problem. - in the context of computer science, over the dimensions of compute, networking and storage, the idea of "scheduling" workloads gradually evolves into the idea of [[id:f822f8f6-89eb-4aa8-ac8f-fdcff3f06fb9][orchestration]] +* Forks and Flavours +** [[id:59305648-ed10-4298-be07-cd67f277f612][Scheduling-K8S]] +** [[id:c50c2084-973a-4f9e-9ab3-946c71b5f2fa][RTLinux]] * Resources - https://container.training/intro-selfpaced.yml.html#832 diff --git a/Content/20240522113815-linux_virtualization.org b/Content/20240522113815-linux_virtualization.org index 6909df6..d41b815 100644 --- a/Content/20240522113815-linux_virtualization.org +++ b/Content/20240522113815-linux_virtualization.org @@ -1,7 +1,8 @@ :PROPERTIES: :ID: 7291bab2-4e69-47ad-ae37-f3da260b1d89 -:ROAM_ALIASES: KVM :END: #+title: Linux Virtualization #+filetags: :cs: +* Relevant Nodes +** [[id:996c1f7e-363d-41a3-b48b-affcae4b95bd][eBPF (extended Berkely Packet Filters)]] diff --git a/Content/20240728174107-keda.org b/Content/20240728174107-keda.org index 092f6e9..410c721 100644 --- a/Content/20240728174107-keda.org +++ b/Content/20240728174107-keda.org @@ -3,3 +3,6 @@ :END: #+title: KEDA (Kubernetes Event-Driven AutoScaler) #+filetags: :cncf:cloud-native: + +* Resources +- https://keda.sh/docs/2.15/concepts/#architecture diff --git a/Content/20240926125731-virtualization.org b/Content/20240926125731-virtualization.org index 340274b..9693664 100644 --- a/Content/20240926125731-virtualization.org +++ b/Content/20240926125731-virtualization.org @@ -3,3 +3,6 @@ :END: #+title: Virtualization #+filetags: :cs: + +* Relevant Nodes +** [[id:7291bab2-4e69-47ad-ae37-f3da260b1d89][Linux Virtualization]] diff --git a/Content/20241014093602-autoscaling_k8s.org b/Content/20241014093602-autoscaling_k8s.org new file mode 100644 index 0000000..428d9a2 --- /dev/null +++ b/Content/20241014093602-autoscaling_k8s.org @@ -0,0 +1,88 @@ +:PROPERTIES: +:ID: 7cb8489b-2b84-4224-b3f9-9f5bf0f38cfe +:END: +#+title: AutoScaling-K8S +#+filetags: :k8s: + +* Cluster AutoScaling +** Definition + - Cluster Autoscaling is a feature in Kubernetes that automatically adjusts the size of a cluster based on the current resource demand. + - It targets the number of nodes, ensuring that workloads have enough resources to run. + +** Components + - *Cluster Autoscaler*: A Kubernetes component responsible for scaling the number of nodes. + - *Node Pools/Groups*: Logical groupings of similar nodes managed by the autoscaler. + - *Metrics*: Utilizes metrics such as CPU and memory usage, as well as pod resource requests and availability. + +** Mechanism + - *Scale Out*: Increases the number of nodes when existing nodes are under pressure, and resources are insufficient. + - *Scale In*: Decreases the number of nodes when they are underutilized, conserving cost and resources. + +** Benefits + - *Cost Efficiency*: Automatically optimizes resource utilization and potentially reduces costs. + - *Reliability*: Ensures workloads have necessary resources, enhancing stability. + - *Scalability*: Seamlessly supports growing or fluctuating workloads. + +** Considerations + - *Pod Disruptions*: Ensuring minimal disruption to running pods during scaling events. + - *Cluster Limits*: Understanding and setting appropriate maximum and minimum node quotas. + - *Rescheduling*: Management of pod scheduling upon node removal. + +** Connections + - *HPA (Horizontal Pod Autoscaler)*: Works alongside cluster autoscaling by adjusting the number of pod replicas. + - *Resource Quotas*: Ensures that autoscaler respects defined resource limits within namespaces. + +** Critique + - *Limitations on Custom Metrics*: While effective on standard metrics, custom use cases may require additional configurations. + - *Latency in Scaling Actions*: There might be a delay in scaling reactions depending on configurations and metric polling intervals. + +** Ideation Strategies + - *Monitoring*: Implement comprehensive monitoring to assess scaling effectiveness. + - *Automation*: Use CI/CD to manage and update scaling strategies as workloads and requirements change. + +** Further Inquiry + - How does autoscaler manage complex workloads with mixed resource requirements? + - What are the best practices for configuring autoscalers for high-availability systems? + - How can one incorporate cost analysis into autoscaling decision frameworks? + +* Vertical Pod AutoScaling +- Vertical Pod Autoscaling (VPA) Overview + - Adjusts the resource requests and limits of Kubernetes pods. + - Focuses on optimizing resource allocation for existing pods, enhancing performance. + - Automatically increases or decreases CPU and memory resource requests based on usage metrics. +- Components of VPA + - Recommender: + - Suggests optimal CPU and memory requests based on historical usage. + - Updater: + - Responsible for evicting pods to apply new recommendations. + - Admission Controller: + - Modifies incoming pod specs to align with recommended resources. +- Benefits of VPA + - Reduces resource wastage by tuning resources closer to actual usage. + - Helps in cost savings by optimizing resource usage. + - Simplifies resource management by alleviating the need for manual tuning. +- Limitations & Considerations + - Pod eviction may cause temporary downtimes; not ideal for stateful applications. + - May not react instantly to sudden spikes in demand; better for gradually evolving workloads. + - Requires a robust monitoring setup to capture accurate usage metrics. +* Horizontal Pod AutoScaling + +** **Overview** + - Automatic adjustment of pod count in Kubernetes + - Based on CPU, memory, or custom metric utilization + - Essential for performance and resource optimization + +** **Components** + - **Metrics Server**: Supplies metrics for decision-making + - **Controller Manager**: Executes scaling operations + +** **Benefits** + - Optimizes resource use through dynamic pod management + - Cost-effective resource allocation in cloud settings + - Improves reliability and availability by responding to traffic changes + +* Tools +** [[id:c50c85ac-0b21-486f-99ac-00f325e2c43c][KEDA (Kubernetes Event-Driven AutoScaler)]] +* Resources +- https://kubernetes.io/blog/2016/07/autoscaling-in-kubernetes/ +- https://github.com/kubernetes/autoscaler diff --git a/Content/20241014101243-bounty_hunting.org b/Content/20241014101243-bounty_hunting.org new file mode 100644 index 0000000..dfdf0d2 --- /dev/null +++ b/Content/20241014101243-bounty_hunting.org @@ -0,0 +1,11 @@ +:PROPERTIES: +:ID: f48a21a7-496e-4068-8b31-0e4a485701a9 +:END: +#+title: Bounty Hunting +#+filetags: :cs: + +Incentivized Intellectual Competitions are great. + +* Resources +** https://console.algora.io/ +** https://github.com/djadmin/awesome-bug-bounty diff --git a/Content/20241014102055-scheduling_k8s.org b/Content/20241014102055-scheduling_k8s.org new file mode 100644 index 0000000..437a103 --- /dev/null +++ b/Content/20241014102055-scheduling_k8s.org @@ -0,0 +1,27 @@ +:PROPERTIES: +:ID: 59305648-ed10-4298-be07-cd67f277f612 +:END: +#+title: Scheduling-K8S +#+filetags: :k8s: + +* Overview + +- The scheduling component in Kubernetes is a core responsibility of the control plane. +- Assign pods to nodes ensuring optimal resource allocation and management. + +* Primary Functionalities +** Resource Optimization +- Considers CPU, memory requests, and constraints. +** Affinity/Anti-affinity Rules +- Enables pod co-location or separation. +** Taints and Tolerations +- Ensures nodes can repel certain pods unless explicitly tolerated. +** NodeSelector and NodeAffinity +- Limits nodes that can host particular pods. +** Priorities and Preemption +- Ensures urgent pods get priority using preemption. +** Scheduler Algorithms: + - Priority Functions: Rank nodes based on set criteria. + - Predicate Functions: Determines if a pod can run on a particular node. +** Custom Schedulers: + - Allows for user-defined policies and scheduling strategies. diff --git a/Content/20241014102716-rtlinux.org b/Content/20241014102716-rtlinux.org new file mode 100644 index 0000000..b79fe92 --- /dev/null +++ b/Content/20241014102716-rtlinux.org @@ -0,0 +1,8 @@ +:PROPERTIES: +:ID: c50c2084-973a-4f9e-9ab3-946c71b5f2fa +:END: +#+title: RTLinux +#+filetags: :linux: + +* Resources + - https://en.wikipedia.org/wiki/RTLinux diff --git a/Content/20241014102929-ebpf_extended_berkely_packet_filters.org b/Content/20241014102929-ebpf_extended_berkely_packet_filters.org new file mode 100644 index 0000000..7b62ed1 --- /dev/null +++ b/Content/20241014102929-ebpf_extended_berkely_packet_filters.org @@ -0,0 +1,12 @@ +:PROPERTIES: +:ID: 996c1f7e-363d-41a3-b48b-affcae4b95bd +:END: +#+title: eBPF (extended Berkely Packet Filters) + + +* Resources +:PROPERTIES: +:ID: 291cfc45-cab6-4c16-a807-3535a1f09233 +:END: + + - https://ebpf.io/what-is-ebpf/