DevOps&SRE Library – Telegram
DevOps&SRE Library
18.4K subscribers
459 photos
3 videos
2 files
5K links
Библиотека статей по теме DevOps и SRE.

Реклама: @ostinostin
Контент: @mxssl

РКН: https://www.gosuslugi.ru/snet/67704b536aa9672b963777b3
Download Telegram
Forwarded from Performance matters!
Алгоритмы управления потоком (Flow Control) в TCP служат для предотвращения перегрузки сети и потерь данных.

Исследования в этой области не прекращаются и на сегодня нам доступно множество вариантов:

* Reno (1986)
* New Reno (1999)
* CUBIC (2004)
* FAST TCP (2005)
* BBRv1 (2016)
* BBRv2 (2019)
* BBRv3 (2023)
* ...

По умолчанию в Linux используется CUBIC. Однако создатели BBR (Google) выкладывают любопытные исследования, где резюмируют:

BBR enables big throughput improvements on high-speed, long-haul links...
BBR enables significant reductions in latency in last-mile networks that connect users to the internet...


Так может нам просто переехать на новые рельсы?

Хотя кажется правильнее поставить вопрос по другому: в каких случаях какой алгоритм может быть предпочтительнее?

————

Алгоритмы Flow Control можно условно разделить на два типа:
1. Loss-based (ориентированы на потери пакетов): Reno, NewReno, CUBIC
2. Delay-based (ориентированы на изменения RTT): FAST TCP, BBRv*

Основная цель любой реализации Flow Control — максимально эффективно использовать пропускную способность канала, сохраняя баланс между скоростью передачи данных и предотвращением перегрузок.

Скорость регулируется через Congestion Window (окно перегрузки) — сколько данных можно отправить без получения подтверждения.

Разница между подходами к контролю перегрузки заключается в методах её определения.

Loss-based (CUBIC)

Алгоритмы этого типа оценивают перегрузку по потерям пакетов.

Пришел дублирующий ACK или сработал Retransmission Timeout (RTO)? Значит есть потери и следовательно канал перегружен - снижаем скорость.
Затем ориентируясь на поступающие ACK, скорость увеличивается, пока не обнаружатся новые потери.

Такой подход может забивать очереди в канале до предела, что и будет приводить к потерям. Реакция носит реактивный характер: перегрузка фиксируется только после её возникновения.

Delay-based (BBR)

В Delay-based алгоритмах, таких как BBR, перегрузка оценивается на основе изменения задержек:
* минимальный RTT (RTT_min) принимается за эталон;
* если текущий RTT (RTT_now) превышает RTT_min, алгоритм предполагает, что канал перегружен, и снижает скорость передачи данных.

Таким образом, BBR стремится избегать заполнения очередей, что позволяет сократить задержки.
Его подход более превентивный: предотвращение перегрузки до её появления.

————

CUBIC проигрывает BBR в сетях с высоким RTT, например, в интернете. Это происходит из-за медленного роста скорости после обнаружения потерь: ACK приходят с задержкой.

Внутри дата-центров, где RTT низкий, CUBIC должен справляться лучше - быстрые ACK ускоряют рост скорости передачи данных.

BBR же в таких сетях может не дать преимуществ. При всплесках трафика он снижает скорость, чтобы избежать заполнения очередей, из-за чего канал используется не полностью. Кроме того, возможны конфликты между алгоритмами, когда та или иная реализация будет захватывать пропусную способность, вытесняя другие. Настоящие войны)

Вообщем как обычно надо быть осторожее!

Почитать:
- https://blog.apnic.net/2017/05/09/bbr-new-kid-tcp-block/
- https://book.systemsapproach.org/congestion.html
- https://tcpcc.systemsapproach.org/

tags: #network #tcp
GitOps Secrets with Argo CD, Hashicorp Vault and the External Secret Operator

In this post, we showcase the External Secret Operator and Hashicorp Vault and focus on 2 important aspects.

- How to avoid saving ANY secrets in Git, including tokens for fetching the application secrets
- How to refresh secrets automatically without pod restarts and application deployments


https://medium.com/containers-101/gitops-secrets-with-argo-cd-hashicorp-vault-and-the-external-secret-operator-eb1eec1dab0d
A hands-on lab: Why running as root in Kubernetes containers is dangerous?

https://medium.com/@marcin.wasiucionek/why-is-running-as-root-in-kubernetes-containers-dangerous-e5f1a116080e
Securing Secrets in Confidential Containers: Usage patterns to avoid

https://itnext.io/securing-secrets-in-confidential-containers-usage-patterns-to-avoid-941388cde546
Kubernetes Operator. Create the one with Kubebuilder

One of possible way to customize the Kubernetes cluster is to use Operators. They extend Kubernetes capabilities by automating the lifecycle management of applications beyond what’s natively supported. This process is powered by Custom Resource Definitions (CRDs) and Custom Resources (CRs). CRDs allow you to define your own API objects, while CRs are the instances of these definitions.


https://fenyuk.medium.com/kubernetes-operator-create-the-one-with-kubebuilder-5d1ac240d0d4
kubectl-modify-secret

kubectl-modify-secrets allows user to directly modify the secret without worrying about base64 encoding/decoding


https://github.com/rajatjindal/kubectl-modify-secret
kubesess

Kubectl plugin managing sessions


https://github.com/Ramilito/kubesess
1
cloudflare-kubernetes-gateway

Manage Kubernetes ingress traffic with Cloudflare Tunnels via the Gateway API.


https://github.com/pl4nty/cloudflare-kubernetes-gateway
kcp

kcp is a Kubernetes-like control plane focusing on:

- A control plane for many independent, isolated “clusters” known as workspaces
- Enabling API service providers to offer APIs centrally using multi-tenant operators
- Easy API consumption for users in their workspaces

kcp can be a building block for SaaS service providers who need a massively multi-tenant platform to offer services to a large number of fully isolated tenants using Kubernetes-native APIs. The goal is to be useful to cloud providers as well as enterprise IT departments offering APIs within their company.


https://github.com/kcp-dev/kcp
bunster

Have you ever wished your shell noscripts could be faster, more portable, and secure ? Bunster brings this to life by transforming your shell noscripts into efficient, standalone binaries that are easy to distribute and deploy across platforms (only unix is supported at the moment).

Unlike other tools, Bunster doesn’t just wrap your noscripts in a binary—it compiles them down to efficient native machine code, leveraging the powerful Go toolchain. This ensures performance, portability, and robustness.

Technically speaking, Bunster in fact is a shell-to-Go Transpiler that generates Go source out of your noscripts. Then, optionally uses the Go Toolchain to compile the code to an executable program.

Bunster targets bash noscripts in particular. The current syntax and features are all inherited from bash. additional shells will be supported as soon as we release v1.


https://github.com/yassinebenaid/bunster
1
opengrep

Static code analysis engine to find security issues in code.


https://github.com/opengrep/opengrep
Scalable and Organized Terraform Project Structure

Due to the lack of official guidelines for structuring larger Terraform projects, teams often face challenges like waiting for state locks and slow apply times. This post presents a scalable Terraform project structure designed to address these challenges.


https://www.vidbregar.com/blog/terraform-project-structure
terraschema

TerraSchema (or terraschema) is a CLI tool which scans Terraform configuration (.tf) files, parses a list of variables along with their type and validation rules, and converts them to a schema which complies with JSON Schema Draft-07.


https://github.com/HewlettPackard/terraschema
Restructuring How We Think About Alerts

Back in Alerts Are Fundamentally Messy, I made the point that the events we monitor are often fuzzy and uncertain. To make a distinction between what is valid or invalid as an event, context is needed, and since context doesn’t tend to exist within a metric, humans go around and validate alerts to add it. As such, humans are part of the alerting loop, and alerts can be framed as devices used to redirect our attention.

In this post, I want to drive this concept a bit further. Rather than focusing the thinking on the events that result in alerts, I want to switch the lens with which we look at the system and center it on the operators who get the message, and on how we can restructure our alerting to play these roles better.


https://www.honeycomb.io/blog/restructuring-how-we-think-about-alerts
Kubernetes Best Practices I Wish I Had Known Before

In this post, I will highlight some crucial Kubernetes best practices. They are from my years of experience with Kubernetes in production. Think of this as the curated “Kubernetes cheat sheet” you wish you had from Day 1. Buckle up; it’s going to be an exciting ride.


https://www.pulumi.com/blog/kubernetes-best-practices-i-wish-i-had-known-before
Node.js 20 upgrade: a journey through unexpected HEAP issues with Kubernetes

https://deezer.io/node-js-20-upgrade-a-journey-through-unexpected-heap-issues-with-kubernetes-27ae3d325646
How to Optimize Kubernetes for Large Docker Images

https://hackernoon.com/how-to-optimize-kubernetes-for-large-docker-images