masto.ai is one of the many independent Mastodon servers you can use to participate in the fediverse.
A general Mastodon server for all languages.

Administered by:

Server stats:

2K
active users

#kubernetes

89 posts65 participants9 posts today

Kubernetes 1.33: упорядоченное удаление ресурсов, изменение алгоритма CrashLoopBackOff и декларативная валидация

Сегодня официально выпустили очередную версию Kubernetes — 1.33. Собрали все 64 изменения в одном материале. Из основных нововведений: упорядоченное удаление ресурсов в пространстве имён на основе логических зависимостей и соображений безопасности, декларативная валидация для нативных API-типов, расширение механизма CredentialProvider, доступ подов к информации о топологии кластера, изменение алгоритма выдержки CrashLoopBackOff, обязательная аутентификация при извлечении private-образов из репозиториев и многое другое.

habr.com/ru/companies/flant/ar

#kubernetes #release #релиз #133 #k8s #обзор #новые_фичи

ХабрKubernetes 1.33: упорядоченное удаление ресурсов, изменение алгоритма CrashLoopBackOff и декларативная валидацияСегодня официально выпустили новую версию Kubernetes — 1.33. Среди главных нововведений — упорядоченное удаление ресурсов в пространстве имён на основе логических зависимостей и соображений...

Been doing some Kubernetes API design today. It's thoughtful but not in quite the way other software design has felt.

I suppose the constraints make it easier to avoid some common mistakes. Spending quite a bit of effort though just wrangling GoLang types and kubebuilder annotations to try and get it how it ought to be.

As of tonight I've moved substantially all of my #HomeLab workloads into my #Kubernetes cluster. Tonight's big push was the Minecraft server. Not doing anything fancy, just a simple StatefulSet, a pvc, and a MetalLB service.

There are a few lingering issues. I need to figure out Multus so #HomeAssistant can get multicast back. I'm considering moving all of my zigbee/zwave/etc gateways into the cluster and running a simple ser2net docker container on the edge nodes.

I also want to move VMSave. It's running on a somewhat expensive DigitalOcean VM today and would be a tiny smidge on the cluster. It's a bit more complicated because it's a super old Rails app currently deployed with Dokku, so it'll keep for another day.

This week's "fun" project: getting #Clickhouse running on #kubernetes at home, with data sharding and redundancy.

I've had a few speedbumps, including dirt in the optics on a redundant network link and an amazingly dumb MTU problem, but it seems to be working finally. I'm now doing a bit of testing to better understand how self-hosted Clickhouse does clusters.

It looks like *if you use their cloud product*, then data sharding and replication Just Works, but if you set up a cluster yourself then you need to declare everything up front when creating tables. So instead of creating a single table via `create table foo (...) ENGINE = MergeTree`, you need to do `create table foo_shard on cluster X (...) ENGINE = ReplicatedMergeTree(...)` in order to create replicated sub-tables per shard, and then add `create table foo on cluster X as foo_shard ENGINE=Distributed(...)` over the top of the per-instance ReplicatedMergeTree shards.

It's (mostly?) just a DDL thing, so querying seems to work as expected, but it's *strange* to create a cluster with a defined shard size and replication level, and then have to repeat yourself per-table in order to use them as declared.

Even better, this all "works" if you declare the per-shard tables as `MergeTree` instead of `ReplicatedMergeTree`, except your data isn't replicated. I watched the disk usage climb on 1/3rd of my nodes while the other 2/3rds sat idle, and had to go back and re-read docs. That's *particularly* surprising, as it could easily lead to data loss.

I'm doing yet another test copy of 1.2B rows of log data (!) right now, and then I'll start looking at what I need to do to cut over.

Also, I'll probably need to do some querying to see why I have 1.2B rows of log data and where it came from. That seems excessive for a couple weeks of logging at home.

Недостатки Istio по сравнению с Cilium: подробное объяснение

В этой статье мы разберём основные недостатки Istio в сравнении с Cilium Service Mesh, чтобы даже начинающий разработчик мог понять, в чём разница и почему некоторые команды выбирают Cilium вместо Istio.

habr.com/ru/articles/903736/

ХабрНедостатки Istio по сравнению с Cilium: подробное объяснениеВ этой статье мы разберём основные недостатки Istio в сравнении с Cilium Service Mesh, чтобы даже начинающий разработчик мог понять, в чём разница и почему некоторые команды выбирают Cilium вместо...

День из жизни облачной команды: как мы провели Demo Day

Привет, Хабр! В этом материале мы не расскажем о рабочих кейсах, технических решениях и привычных темах для нашего блога. Лучше — мы покажем немного всего этого и поделимся впечатлениями о первом Demo Day облачной команды Рег.ру. Внутри: краткое ревью докладов, анонсы новых облачных релизов, которые мы планируем к запуску, и немного фото. Полетели!

habr.com/ru/companies/runity/a

ХабрДень из жизни облачной команды: как мы провели Demo DayПривет, Хабр! В этом материале мы не расскажем о рабочих кейсах, технических решениях и привычных темах для нашего блога. Лучше — мы покажем немного всего этого и поделимся впечатлениями о первом Demo...