Skip to content

Commit

Permalink
updates
Browse files Browse the repository at this point in the history
Signed-off-by: (Bit-Mage) <[email protected]>
  • Loading branch information
(Bit-Mage) committed Oct 21, 2024
1 parent 77e553f commit 6d6ed83
Show file tree
Hide file tree
Showing 6 changed files with 164 additions and 1 deletion.
4 changes: 4 additions & 0 deletions Content/20241014204106-operators_k8s.org
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,10 @@
#+title: Operators-K8S
#+filetags: :k8s:

* Whitepaper
- https://github.com/cncf/tag-app-delivery/blob/163962c4b1cd70d085107fc579e3e04c2e14d59c/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md
- is about [[id:fbf4b86f-9f3b-4fc7-aa76-1112c755eb1a][operators]] in general
- exploring in a dedicated node
* OperatorHub.io
- https://operatorhub.io/
* Resources
Expand Down
142 changes: 142 additions & 0 deletions Content/20241021084553-operator.org
Original file line number Diff line number Diff line change
@@ -0,0 +1,142 @@
:PROPERTIES:
:ID: fbf4b86f-9f3b-4fc7-aa76-1112c755eb1a
:END:
#+title: Operator
#+filetags: :tool:cs:

* CNCF Operator White Paper
** Table of Contents
- Executive Summary
- Introduction
- Document Goal
- Target Audience
- Foundation
- Operator Design Pattern
- Operator Characteristics
- Operator Components in Kubernetes
- Operator Capabilities
- Security
- Operator Developer
- Application Developer (Operator-"Users")
- Operator Frameworks for Kubernetes
- CNCF Operator Framework
- Kopf
- kubebuilder
- Metacontroller
- Operator Lifecycle Management
- Upgrading the Operator
- Upgrading Declarative State
- Managing CRD Relations
- Use Cases for an Operator
- Prometheus Operator
- GitOps Operator
- Successful Patterns
- Single Application Management
- Operator of Operators
- One CRD per Controller
- Publishing and Finding Operators
- Further Reading
- Designing Operators
- Requirement Analysis
- Custom or Third-party Operator
- Tool Selection
- Programming Language
- Design Considerations
- References
- Emerging Patterns
- Operator Lifecycle Management
- Policy-Aware Operators
- References
- Conclusion
- Related Work
- Acknowledgements
- Contributors
- Reviewers

** Executive Summary
- Application infrastructure maintenance requires repetitive tasks.
- Operators encapsulate activities, checks, and state management.
- In Kubernetes, operators extend API functionality for automation.
- Operators enhance development speed, reduce errors, and increase autonomy.
- Document serves as a reference for implementing operator best practices.

** Introduction
- Defines operators beyond Kubernetes, outlining characteristics and patterns.
- Highlights difference from controllers and provides best practices.

** Document Goal
- Defines operators for cloud-native applications in Kubernetes.

** Target Audience
- For application developers, Kubernetes operators, and service providers.
- Assumes basic Kubernetes knowledge (Pods, Deployments).

** Foundation
- Operators automate state management leveraging Kubernetes features.
- Extend automation to highly capable offerings across platforms.
- Export automation concepts beyond Kubernetes.

** Operator Design Pattern
- Manages resources using domain-specific knowledge and declarative state.
- Reduces manual work by coding management knowledge.
- User defines desired state; operators adjust to match real state.

** Operator Characteristics
- Extends API with domain knowledge, like Prometheus object management.
- Dynamic configuration via custom objects enhances validation and autonomy.
- Automation for operational tasks ensures reliability and consistency.

** Operator Components in Kubernetes
- Combines Kubernetes controllers and watched objects.
- Desired state defined in custom resources; reconciled with current state.
- Control Loop ensures specified state matches real state.

** Operator Capabilities
- Capabilities include installation, upgrades, backup, recovery, scaling, etc.
- Operators create, upgrade, and manage resources automatically.
- Advanced functions include auto-scaling, remediation, and configuration tuning.

** Security
- Security considerations for developers and users.
- Developers should focus on transparency, documentation, and scope.
- Users manage namespaces and RBAC carefully for secure deployment.

** Operator Frameworks for Kubernetes
- Frameworks like CNCF Operator Framework, Kopf, kubebuilder for ease of use.
- Provide features like dependency management, discoverability, and stability.

** Operator Lifecycle Management
- Manage operator versioning, maintain managed resource states during upgrades.
- Oversee complex relations and dependencies among multiple CRDs.

** Use Cases for an Operator
- Examples like Prometheus Operator and GitOps highlight practical implementations.
- Operators can manage applications and non-application configurations declaratively.

** Successful Patterns
- Focus on managing single applications, utilizing operator-of-operators architecture.
- Ensure clear separation of concerns and efficient resource management.

** Designing Operators
- Analyze requirements, choose between custom and third-party Operators.
- Use appropriate tooling and programming languages for development.
- Design operators to suit operational needs and ensure backward compatibility.

** Emerging Patterns
- Trends like dynamic authorization and Operator reuse provide new capabilities.
- Policy-aware operators and maintenance transparency are evolving considerations.

** Conclusion
- Operators enhance orchestration capabilities but introduce complexities.
- Critical to weigh benefits against implementation challenges.

** Related Work
- Expands on initial CoreOS blog post defining Operator roles.
- References various documents for deepened understanding and context.

** Acknowledgements
- Community-driven effort of CNCF TAG App-Delivery Operator Working Group.
- Recognition of contributors and reviewers.
* Resources
- https://github.com/cncf/tag-app-delivery/blob/163962c4b1cd70d085107fc579e3e04c2e14d59c/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md

17 changes: 16 additions & 1 deletion Content/bib/references.bib
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ @inproceedings{foster_cloud_2008
author = {Foster, Ian and Zhao, Yong and Raicu, Ioan and Lu, Shiyong},
month = nov,
year = {2008},
keywords = {A.1, and Cluster Computing, C.2.4, Computer Science - Distributed, Parallel},
keywords = {and Cluster Computing, Computer Science - Distributed, Parallel, A.1, C.2.4},
pages = {1--10},
annote = {arXiv:0901.0131 [cs]},
}
Expand Down Expand Up @@ -697,3 +697,18 @@ @article{zhang_poisson-gaussian_2019
annote = {Comment: Camera-ready version for CVPR 2019. The Fluorescence Microscopy Denoising (FMD) dataset is available at https://drive.google.com/drive/folders/1aygMzSDdoq63IqSk-ly8cMq0\_owup8UM},
file = {arXiv Fulltext PDF:/home/rp152k/Zotero/storage/Z8F3K8VP/Zhang et al. - 2019 - A Poisson-Gaussian Denoising Dataset with Real Flu.pdf:application/pdf;arXiv.org Snapshot:/home/rp152k/Zotero/storage/QV8H6RY4/1812.html:text/html},
}

@misc{saraswathi_exposition_2024,
title = {An {Exposition} of {Pathfinding} {Strategies} {Within} {Lightning} {Network} {Clients}},
url = {http://arxiv.org/abs/2410.13784},
doi = {10.48550/arXiv.2410.13784},
abstract = {The Lightning Network is a peer-to-peer network designed to address Bitcoin's scalability challenges, facilitating rapid, cost-effective, and instantaneous transactions through bidirectional, blockchain-backed payment channels among network peers. Due to a source-based routing of payments, different pathfinding strategies are used in practice, trading off different objectives for each other such as payment reliability and routing fees. This paper explores differences within pathfinding strategies used by prominent Lightning Network node implementations, which include different underlying cost functions and different constraints, as well as different greedy algorithms of shortest path-type. Surprisingly, we observe that the pathfinding problems that most LN node implementations attempt to solve are NP-complete, and cannot be guaranteed to be optimally solved by the variants of Dijkstra's algorithm currently deployed in production. Through comparative analysis and simulations, we evaluate efficacy of different pathfinding strategies across metrics such as success rate, fees, path length, and timelock. Our experiments indicate that the strategies used by LND tend to be advantageous in terms of payment reliability, Eclair tends to result in paths with low fees, and that LDK exhibits average reliability with larger fee levels for smaller payment amounts; furthermore, CLN stands out for its minimal timelock paths. Additionally, we investigate the impact of Lightning node connectivity levels on routing efficiency. The findings of our analysis provide insights towards future improvements of pathfinding strategies and algorithms used within the Lightning Network.},
urldate = {2024-10-20},
publisher = {arXiv},
author = {Saraswathi, Sindura and Kümmerle, Christian},
month = oct,
year = {2024},
note = {arXiv:2410.13784},
keywords = {Computer Science - Computational Engineering, Finance, and Science, Computer Science - Cryptography and Security, Computer Science - Networking and Internet Architecture, Computer Science - Social and Information Networks},
file = {Preprint PDF:/home/rp152k/Zotero/storage/D93TB9XV/Saraswathi and Kümmerle - 2024 - An Exposition of Pathfinding Strategies Within Lightning Network Clients.pdf:application/pdf;Snapshot:/home/rp152k/Zotero/storage/84R97B25/2410.html:text/html},
}
Binary file modified Content/images/plant-uml.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified Content/images/plantuml-seq.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
2 changes: 2 additions & 0 deletions Content/index.org
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,8 @@ I also consider deliberately intellectually [[id:f3347380-f482-4077-a89b-a3ff059
- a cache for ideas that may never see the light of day again.
- or they just might...
* Stream
** 0x22EA
- my mechanisms are pretty smooth around the edges now
** 0x22E7
- allocating every friday half to clear up all the ancillary tech that I get into..
- I tend to push a lot of smaller interesting technologies and things into my INQ and NA
Expand Down

0 comments on commit 6d6ed83

Please sign in to comment.