mirror of
https://github.com/ByteByteGoHq/system-design-101.git
synced 2026-04-09 19:47:24 -04:00
ee4b7305a2
This PR adds all the guides from [Visual Guides](https://bytebytego.com/guides/) section on bytebytego to the repository with proper links. - [x] Markdown files for guides and categories are placed inside `data/guides` and `data/categories` - [x] Guide links in readme are auto-generated using `scripts/readme.ts`. Everytime you run the script `npm run update-readme`, it reads the categories and guides from the above mentioned folders, generate production links for guides and categories and populate the table of content in the readme. This ensures that any future guides and categories will automatically get added to the readme. - [x] Sorting inside the readme matches the actual category and guides sorting on production
71 lines
2.1 KiB
Markdown
71 lines
2.1 KiB
Markdown
---
|
||
title: "Top 10 Kubernetes Design Patterns"
|
||
description: "Explore the top 10 Kubernetes design patterns with detailed explanations."
|
||
image: "https://assets.bytebytego.com/diagrams/0372-top-10-k8s-design-patterns.png"
|
||
createdAt: "2024-02-19"
|
||
draft: false
|
||
categories:
|
||
- devops-cicd
|
||
tags:
|
||
- "Kubernetes"
|
||
- "Design Patterns"
|
||
---
|
||
|
||
|
||
|
||
## Foundational Patterns
|
||
|
||
These patterns are the fundamental principles for applications to be automated on k8s, regardless of the application's nature.
|
||
|
||
* **Health Probe Pattern**
|
||
|
||
This pattern requires that every container must implement observable APIs for the platform to manage the application.
|
||
|
||
* **Predictable Demands Pattern**
|
||
|
||
This pattern requires that we should declare application requirements and runtime dependencies. Every container should declare its resource profile.
|
||
|
||
* **Automated Placement Pattern**
|
||
|
||
This pattern describes the principles of Kubernetes’ scheduling algorithm.
|
||
|
||
## Structural Patterns
|
||
|
||
These patterns focus on structuring and organizing containers in a Pod.
|
||
|
||
* **Init Container Pattern**
|
||
|
||
This pattern has a separate life cycle for initialization-releated tasks.
|
||
|
||
* **Sidecar Pattern**
|
||
|
||
This pattern extends a container’s functionalities without changing it.
|
||
|
||
## Behavioral Patterns
|
||
|
||
These patterns describe the life cycle management of a Pod. Depending on the type of the workload, it can run as a service or a batch job.
|
||
|
||
* **Batch Job Pattern**
|
||
|
||
This pattern is used to manage isolated atomic units of work.
|
||
|
||
* **Stateful Service Pattern**
|
||
|
||
This pattern creates distributed stateful applications.
|
||
|
||
* **Service Discovery Pattern**
|
||
|
||
This pattern describes how clients discover the services.
|
||
|
||
## Higher-Level Patterns
|
||
|
||
These patterns focus on higher-level application management.
|
||
|
||
* **Controller Pattern**
|
||
|
||
This pattern monitors the current state and reconciles with the declared target state.
|
||
|
||
* **Operator Pattern**
|
||
|
||
This pattern defines operational knowledge in an algorithmic and automated form.
|