Пани з CatOps добре статтю описали, тож рекомендую статтю і їхній канал для тих, кому цікаво більше постів по цій темі

A great article about Kubernetes routing.

Yes, things described at the beginning are basic, but then the article explains, how things work under the hood using IPTABLES as an example. So, this article is great both for those who just learn K8s, and those who work with it, but want to dig deeper.

BTW, do you remember all the chains that IPTABLES have? :D

#kubernetes #networking

Новинка в TF
https://www.hashicorp.com/blog/terraform-stacks-explained

Мій досвід по складанню CKA сертифікації, складав майже рік тому, і цей оригінальний текст писав тоді відповідно, якось не було думки запостити, але зараз наближаються знижки(або вже є), тож рекомендую скористатись ними.

“I decided to pass certification in November 2023, during Black Friday's discounts on the Linux Foundation portal, as it seemed to be the best offer, just so you know. After purchase, you will have 1 year to pass the certification and 1 more attempt to retake, keep it in mind.

I have a background in working with Kubernetes so the whole preparation took 1 month of romantic evenings dealing with courses and practicing. Talking about courses I will suggest the exceptionally good course on Udemy (https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/?couponCode=ST22FS22724), I just did not use anything else. In this course you will have some lectures, but what better you will have practice labs on each section and the mock exams at the end, very powerful.



Speaking about the exam itself you can use the official Kubernetes documentation during the exam, so you do not need to remember the exact nested level of capabilities, but of course, you need to know where to find and some understanding of resource syntax, which you are creating. This can save you time and even points because the exam lasts 2 hours and that's not much, I have used them completely. Honestly, the exam environment is frankly bad, notably laggy, and creepy so you need to be prepared for such an astonishment because I was not...



Furthermore, I want to mention some possible tasks to give you some understanding of the exam itself. For example: Create a ClusterRole, assign it to SA, and run the pod from this SA; Backup and restore etcd service; Upgrade cluster version; Setup cluster with kubeadm; Create PV, PVC and assign it the pod. Also a lot of tasks of changing existing resources, such as resizing, redeploying, scaling, and so on.”

P.S. і ще мають звʼявитись коменти тепер на каналі

Привіт, хороший товариш порадив якось сайт, який є вижимкою частинки книги по SQL перформансу, яка стосується індексів. Я знаю, що не всім актуально тут по різним причинам, проте у будь-якому випадку раджу ознайомитись тим, хто відчуває, що має гепи в індексах і їх розумінні або ж взагалі новий в цій темі.
https://use-the-index-luke.com/

Варто зауважити, що оскільки це вижимка з більш великої теми, то не все тут розібрано прям по максимуму глибоко, тож я думаю, що тим, кому буде цікаво, ознайомиться з повною версією книги.

Взагалі тема перформансу баз даних доволі об'ємна, цікава і важлива. За власними спостереженнями багато людей не приділяють цьому достатньо уваги, через що оптимізація робиться через збільшення database класу в AWS RDS😁

Буду вдячний, якщо хтось вирішить поділитись своїми матеріалами на цю тему в коментарях.

Не можу не поділитись знахідкою шановного пана, сам побавився, тож рекомендую для ознайомлення

такс, тут знайшли вразливості в Ingress nginx, ніколи такого не було і от знову.

https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities

https://www.wiz.io/crying-out-cloud/ingress-nightmare-how-a-single-request-could-take-over-your-k8s-cluster

Привіт, давно не було постів, згадав, що давно хотів написати про одне рішення, яке довелось імплементувати. Можливо, комусь буде цікаво, а хтось візьме собі до уваги.
Загалом одразу визначу контекст: будемо говорити за Google Cloud і його конкретний сервіс, а саме Private Service Connect. Вирішив написати пост, бо такий солюшн непопулярний, а ніякого rocket science в ньому немає.

Так от, яка проблема? Часто нам потрібно організувати доступ до ресурсів, які знаходяться за межами нашої VPC, але ганяти трафік через публічну мережу ніхто не хоче(і не треба так!;)), тож більшість рішень, коли нашим ресурсам у VPC потрібен доступ до ресурсів іншої VPC, базуються на VPC peering, Shared VPC і інших похідних об'єднань VPC. Однак доступ до всієї VPC нам, скоріш за все, не потрібен, і за найкращими сек'юрними практиками ми маємо обмежувати доступ до інших ресурсів(які не приймають участі в нашому сценарії), але так само часто на це забивають, і в підсумку у вас виходить дві VPC, де можна ганяти трафік як заманеться. А і це я ще нічого не кажу про overlapping VPC CIDRs...

Тепер трошки про наш сценарій: у нас був основний проект, в якому було декілька баз, які були розгорнуті в GKE Kubernetes кластері, а також проект по аналізу даних, зона дата інженерів — це були різні GCP проекти, відповідно різні VPC. Основний проект був доволі великий, з купою ресурсів, і хотілось надати доступ виключно до баз і, звичайно без пірингу, бо навіщо нам пірити мережі задля декількох баз? Звучить нераціонально.

Тож я почав шукати рішення, після огляду різноманітних варіантів об'єднань VPC натрапив на Private Service Connect і подумав, що це може бути саме те, що потрібно. Загалом архітектура сервісу доволі проста: у вас є Publisher(той, хто "надає" ендпоінт) і Consumer(відповідно той, хто буде до цього ендпоінта підключатись).

Аби заекспоузити ендпоінт БД з K8s ми створили NLB, таким чином отримавши приватний айпішник в межах VPC. Тут варто зауважити, що в Private Service Connect є інтеграція з GKE, і тому Publisher можна легко створити за допомогою ресурсу в k8s. Окремо також потрібно створити сабнет для Private Service Connect — ця конфігурація залишилась в тераформі.

apiVersion: networking.gke.io/v1
kind: ServiceAttachment
metadata:
  name: test-db
  namespace: pg
spec:
  connectionPreference: ACCEPT_AUTOMATIC
  natSubnets:
    - stg-test-db-psc
  proxyProtocol: false
  resourceRef:
    kind: Service
    name: test-db-psc

Зі сторони паблішера це все, далі зі сторони консьюмера потрібно зарезервувати статичний айпішник, forwarding rule і на цьому... все. Загалом весь сетап доволі простий. Я також знайшов гугловську лабу зі схожим сценарієм, тут є і картинки і більше команд, тож для зацікавлених раджу ознайомитись . Буду радий отримати фідбек, критику та пропозиції ваших рішень;)

Cloudflare пишуть, як відбили найбільшу (задокументовану) DDOS атаку. Пост не новий, проте для тих, хто пропустив буде цікаво. Вони також приділили трохи часу на опис типів атак. Загалом раджу час від часу заглядати в блог Cloudflare, де може бути щось цікавеньке.

https://blog.cloudflare.com/defending-the-internet-how-cloudflare-blocked-a-monumental-7-3-tbps-ddos/

Прочитав невеличку(196с.) книжечку по безпеці і моніторингу куба, доволі вичерпно.

Багато популярних практик описується, як от — сканування імеджів, тестування, RBAC, service mesh, і різного роду шифрування. Проте також є серйозні практики, які більшість загалом не використовують(або більшість в моїй бульбашці), як-от захист від атак/пробиття контуру кластера.

З моїх спостережень, багато хто навіть не користуються Network policies, тож якщо ви займаєтесь менеджментом куб кластера і не в курсі за це — рекомендую звернути увагу👀. Загалом буду вдячний, якщо поділитесь вашими best security практиками, які активно використовуєте у ваших системах, в коментах.

Раджу як мінімум з цією книгою ознайомитись, можливо пройтись по частинам, які хочеться підтягнути або осягнути з нуля. Я впевнений, що кожен для себе відкриє щось нове.
І пам'ятаймо, що роль кібербезпеки в наш час переоцінена /s

P.S. ще можна забрати безкоштовно;)

p.s.s. майже немає реклами calico🐯;)

https://flaws.cloud/

Один AWS certified товариш підкинув класний сайт, де можна краще ознайомитись з security проблемами, пов'язаними з AWS. Великий плюс у тому, що можна самостійно шукати вразливості — сайт доволі інтерактивний, а не просто набір сухих статей про безпеку.

Наприклад, на першому рівні вам потрібно буде через вразливість S3 бакета знайти посилання на другий рівень — what a fun!

Якщо ви хочете більше дізнатись про те, як працюють Kubernetes оператори під капотом, то раджу наступну статтю, проте для кращого розуміння — варто почати з першої частини, посилання на яку є на початку цієї статті. Автор починає розповідь з самих основ і демонструє приклад створення власного оператора.

До речі, рекомендую цього автора і його сайт, він розказує про багато практичних речей пов'язаних з DevOps та інфрою. До того ж, робить це цікаво та з прикладами, багато з яких можна брати і реалізовувати в себе.

Топ стаття від фігми про міграцію на k8s. Хоча технічних деталей тут не дуже багато(але вони є), написано дуже цікаво. У майбутньому я буду займатись схожою міграцією, сподіваюсь буде змога також розповісти щось цікаве)

https://www.figma.com/blog/migrating-onto-kubernetes/

Доволі корисна табличка, якщо перед вами стоїть вибір Ingress контролера(Проте пам'ятаймо, що Куб вже створив наслідника інгреса і поступово все туди буде переїжджати). Пам'ятаю ми якось на це купу сторіпоінтів витратили... хоча потрібно було просто сісти проаналізувати/поспілкуватись з досвідченими людьми.

Дуже хотів по мотивам останніх подій запостити — https://www.cloudflare.com/learning/dns/what-is-dns/
Я думаю, більшість тут все ж в курсі за DNS і як він працює, але стаття хороша для "рефрешу" знань:)

https://blog.cloudflare.com/18-november-2025-outage/

Навіть не dns