Java for Beginner
742 subscribers
708 photos
196 videos
12 files
1.14K links
Канал от новичков для новичков!
Изучайте Java вместе с нами!
Здесь мы обмениваемся опытом и постоянно изучаем что-то новое!

Наш YouTube канал - https://www.youtube.com/@Java_Beginner-Dev

Наш канал на RUTube - https://rutube.ru/channel/37896292/
Download Telegram
Продолжаем выбирать темы для разбора и голосовать за рассмотрение предложенных! 🤓

Голосуем за тему к рассмотрению в эти выходные!

Выбираем новую тему!
(можете предложить что-то из того, что предлагали на прошлой и позапрошлых неделях и что проиграло в голосовании!)

Не стесняемся! ✌️
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Вопрос с собеседований

Ч
то такое string concatenation оптимизация в Java? 🤓

Ответ:

Компилятор Java оптимизирует конкатенацию строк с помощью StringBuilder под капотом для эффективности.

Пример:
String s = "a" + "b" + "c"; // Компилятор преобразует в StringBuilder.append()

Для циклов лучше явно использовать StringBuilder для избежания создания множества временных объектов.


#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
🗓 История IT-технологий сегодня — 5 сентября


ℹ️ Кто родился в этот день

Роберт Хит Деннард (5 сентября 1932 г. – 23 апреля 2024 г.) — изобретатель DRAM и автор принципа «масштабирование Деннарда», фундамент для роста вычислительной техники.

Стеван Манев Додунеков (болг. Стефан Манев Додунеков; 5 сентября 1945, Килифарево — 5 августа 2012, София) — болгарский математик/информатик, работы по кодированию и криптографии, руководил ИМИ БАН.


🌐 Знаковые события

1977 — Запущена автоматическая межпланетная станция «Вояджер-1».

1990 — Компания IBM впервые анонсировала последовательный оптический интерфейс ESCON.


#Biography #Birth_Date #Events #05Сентября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Сети, Volume, ENV и логи в Docker

Основы: архитектурные компоненты Docker

Что такое Docker-сеть? Концепция изоляции и коммуникации
Docker-сеть — это виртуальная изолированная среда, построенная на механизмах ядра Linux (network namespaces, iptables, виртуальные Ethernet-пары), обеспечивающая коммуникацию между контейнерами и внешним миром.

Каждая сеть предоставляет контейнерам собственное сетевое пространство, включающее:
- Интерфейсы (loopback, Ethernet),
- Таблицы маршрутизации,
- Правила firewall (iptables/nftables).


Без сетей контейнеры не смогли бы взаимодействовать друг с другом или с хостом. Изоляция предотвращает конфликты портов (например, два контейнера с веб-сервером на порту 80) и обеспечивает безопасность через segmentation.


Docker Networking: bridge, host, overlay

1. Bridge (по умолчанию)
Bridge-сеть — изолированная сеть на уровне хоста, где контейнеры общаются через виртуальный коммутатор (bridge). Это аналог домашнего роутера: контейнеры получают внутренние IP-адреса, а трафик к внешнему миру проходит через NAT.

Как это работает:
- Docker Daemon создает bridge-интерфейс (обычно docker0) на хосте. Это виртуальный коммутатор уровня L2.

- Для каждого контейнера генерируется virtual Ethernet pair (veth):
- Один конец подключается к docker0 (на хосте),
- Второй — к network namespace контейнера (изолированное сетевое пространство).

- Network namespace — механизм ядра Linux, изолирующий сетевые ресурсы (интерфейсы, таблицы маршрутизации). Контейнер «видит» только свои интерфейсы, не мешая другим процессам.

- Трафик между контейнерами фильтруется через iptables:
- Правила NAT (POSTROUTING) маскируют исходящие пакеты (SNAT),
- Правила FORWARD разрешают коммуникацию внутри сети.


Пример:
docker run -d --name web nginx

- Контейнер web получает IP вида 172.17.0.2 в сети docker0.
- При запросе curl http://web с другого контейнера в той же сети:
1. DNS-резолвер Docker преобразует web в
172.17.0.2,
2. Пакет передается через veth-пару в docker0,
3. Доставляется в контейнер web без участия хоста.


Нюансы:
- Проброс портов (-p 8080:80) добавляет правило в цепочку DOCKER iptables, перенаправляющее трафик с хоста в контейнер.
- Для связи между контейнерами в разных bridge-сетях требуется user-defined bridge (создается через docker network create).



2. Host-сеть
Контейнер использует сетевой стек хоста напрямую, без изоляции. Это как запуск процесса на хосте, но с изоляцией процессов и файловой системы.

Как это работает:
- Контейнер не получает отдельный network namespace. Все сокеты хоста доступны внутри контейнера.
- Порты, занятые контейнером (например, 80), недоступны другим процессам хоста.


Пример:
docker run --network host -d nginx

- Nginx слушает порт 80 на хосте напрямую.
- Нет накладных расходов на NAT, но конфликты портов неизбежны при запуске нескольких сервисов.


Когда использовать:
- Для высокопроизводительных сетевых утилит (tcpdump, haproxy),
- В embedded-системах, где изоляция не требуется.



3. Overlay-сеть
Сеть для multi-host оркестрации (требует Docker Swarm или Kubernetes). Позволяет контейнерам на разных серверах общаться как в одной локальной сети.

Как это работает:
- Использует VXLAN (Virtual Extensible LAN) для туннелирования трафика между узлами.
- VXLAN — технология инкапсуляции L2-кадров в UDP-пакеты. Каждый пакет получает заголовок с VXLAN Network Identifier (VNI), идентифицирующим сеть.
- Распределенное хранилище (Consul/Etcd) синхронизирует состояние сети между нодами.

- Encap/Decap:
- При отправке пакета с узла A на узел B:
1. Данные инкапсулируются в UDP-дейтаграмму с VNI,
2. Передаются по физической сети,
3. На узле B извлекаются из туннеля.


Пример:
docker network create -d overlay my_overlay

- Требует открытия портов:
- 7946 (TCP/UDP) — для обнаружения узлов,
- 4789 (UDP) — для VXLAN-трафика.


Нюансы:
- Задержки выше, чем в bridge, из-за инкапсуляции.
- В Kubernetes вместо overlay используется CNI (Container Network Interface) с плагинами (Calico, Flannel).


#Java #middle #Docker #Bridge #Host #Overlay
👍3🔥1
Volumes и bind-mounts: управление данными

Volume — это механизм хранения данных, независимый от жизненного цикла контейнера. В отличие от данных внутри контейнера (которые удаляются при его остановке), volume сохраняет информацию даже после удаления контейнера. Это достигается через выделение отдельного места на диске хоста с управлением через Docker Engine.

Зачем это нужно?
- Персистентность данных (БД, конфиги),
- Обмен данными между контейнерами,
- Изоляция от изменений на хосте.



1. Named Volumes
Именованные тома, управляемые Docker. Хранятся в /var/lib/docker/volumes/.

Как это работает:
- Docker создает том в /var/lib/docker/volumes/db_data/_data.
- При монтировании в контейнер используется bind mount с флагом rprivate (изоляция от изменений на хосте).
- OverlayFS: Для образов с несколькими слоями volume монтируется как верхний writable-слой.


Пример:
volumes:
db_data:
services:
db:
volumes:
- db_data:/var/lib/postgresql/data

- При старте контейнера:
1. Docker проверяет наличие тома db_data,
2. Если том новый — инициализирует его пустой директорией,
3. Монтирует в контейнер через mount-системный вызов.


Нюансы:
- Владелец тома — пользователь внутри контейнера (например, postgres в образе PostgreSQL).
- При удалении контейнера том не удаляется — требуется docker volume prune.



2. Bind Mounts
Прямое сопоставление директории хоста и контейнера.

Как это работает:
- Ядро Linux связывает inode хоста (./logs) и контейнера (/app/logs) через mount namespace.
- Все операции записи в /app/logs отражаются на хосте в ./logs.


Пример:
services:
app:
volumes:
- ./logs:/app/logs

- inode — уникальный идентификатор файла в файловой системе. При bind mount inode хоста и контейнера совпадают.

Критические ограничения:
- Производительность ниже, чем у named volumes (отсутствие кэширования overlayfs),
- Риск повреждения данных при одновременной записи из хоста и контейнера.


#Java #middle #Docker #Volumes
👍3🔥1
Переменные окружения (ENV, .env)

Это динамические пары ключ=значение, доступные процессу во время выполнения. В Linux они хранятся в памяти процесса как null-terminated строки (например, PATH=/usr/bin).

Как это работает в Docker:
- При старте контейнера Docker Daemon добавляет переменные в process namespace через execve-системный вызов.
- Значения копируются в память процесса (PID 1 контейнера) при его создании.


Пример:
environment:
DB_URL: jdbc:postgresql://db:5432/mydb


- Внутри контейнера переменная доступна через:

  cat /proc/1/environ | tr '\0' '\n'  # PID 1 — процесс Java

Нюансы безопасности:
- Переменные видны в docker inspect и через /proc/<pid>/environ,
- Никогда не передавайте секреты через environment — используйте Docker Secrets или Vault.



Продвинутые сценарии

Секреты: от Docker Secrets до Vault

Что такое секреты в контексте Docker?
Это конфиденциальные данные (пароли, токены), требующие защищенного хранения и передачи. В отличие от переменных окружения, секреты шифруются и изолируются от неавторизованного доступа.

Docker Secrets (Swarm mode)

Как это работает:
- Секреты монтируются как файлы в /run/secrets/ через tmpfs (RAM-диск).
- При монтировании устанавливаются права 000 — доступ только через docker exec.
- Шифрование: секреты передаются по TLS между менеджерами Swarm и хранятся в Raft-логе шифрованными.


Пример:
echo "my_password" | docker secret create db_password -

- Raft-лог: Алгоритм консенсуса для распределенных систем. В Swarm используется для синхронизации состояния секретов.

Недостатки:
- Не подходит для Compose (требует Swarm),
- Нет ротации — при обновлении секрета нужно пересоздавать сервис.



Конфигурация логирования: драйверы и их особенности

Что такое драйвер логирования?

Это модуль, определяющий, как Docker перехватывает и обрабатывает stdout/stderr контейнера. По умолчанию используется json-file, но можно подключить сторонние системы (Fluentd, Syslog).

Как это работает:
- Docker Daemon перехватывает потоки stdout/stderr через pipe (канал межпроцессного взаимодействия).
- Данные передаются в драйвер, который форматирует и отправляет их в указанное место.


Пример для gelf:
logging:
driver: gelf
options:
gelf-address: "udp://graylog:12201"


- GELF (Graylog Extended Log Format) — бинарный формат для структурированных логов.

Поддерживает поля:
  {"version": "1.1", "host": "app", "short_message": "Error", "level": 3}

Нюансы:
- UDP не гарантирует доставку — возможна потеря логов при перегрузке,
- Для надежности используйте tcp вместо udp, но снизится производительность.


#Java #middle #Docker #env
👍4🔥1
Тонкая настройка JVM через переменные окружения

Control Groups (cgroups) — механизм ядра Linux для ограничения, учета и изоляции использования ресурсов (CPU, память, дисковый I/O) группой процессов. Docker использует cgroups для ограничения ресурсов контейнера.

Как это влияет на JVM?
- Если в контейнере установлен лимит памяти (--memory=512m), JVM не видит его по умолчанию и пытается выделить память, превышающую лимит.

Решение:
  environment:
JAVA_TOOL_OPTIONS: "-XX:MaxRAMPercentage=75.0"

- -XX:MaxRAMPercentage указывает JVM использовать 75% от лимита cgroups, а не от общей памяти хоста.


Как это работает:
- JVM читает лимиты из /sys/fs/cgroup/memory/memory.limit_in_bytes (путь внутри cgroup контейнера).
- При старте выделяет heap через mmap с учетом лимита.


Критические ошибки:
- Если -Xmx превышает лимит cgroups, JVM упадет с Native memory allocation (mmap) failed.
- Для контейнеров никогда не используйте `-Xmx` без учета cgroups.



Пример: Java-сервис с ENV и логами в volume

docker-compose.yml
version: '3.8'
services:
app:
build: ./app
environment:
DB_URL: jdbc:postgresql://db:5432/mydb
DB_PASSWORD: ${DB_PASSWORD}
volumes:
- app_logs:/app/logs
logging:
driver: json-file
options:
max-size: "50m"
networks:
- app_net

db:
image: postgres:15
environment:
POSTGRES_DB: mydb
POSTGRES_PASSWORD: ${DB_PASSWORD}
volumes:
- pg_data:/var/lib/postgresql/data
networks:
- app_net

volumes:
app_logs:
driver: local
pg_data:

networks:
app_net:
driver: bridge


Концептуальное объяснение
:
1. Сеть app_net:
- Создает bridge-сеть через docker network create.
- Контейнеры app и db получают IP в подсети
172.18.0.0/16 и могут общаться по именам (db:5432).

2. Том pg_data:
- Хранится в /var/lib/docker/volumes/pg_data/_data.
- При старте PostgreSQL инициализирует данные в этом каталоге.


3. Логирование:
- Драйвер json-file пишет логи в /var/lib/docker/containers/<id>/<id>-json.log.
- При достижении 50m файл ротируется, сохраняя 3 архива.


Код Java-приложения:
public class Main {
public static void main(String[] args) {
String dbUrl = System.getenv("DB_URL"); // Чтение из process namespace
try (Connection conn = DriverManager.getConnection(
dbUrl, "user", System.getenv("DB_PASSWORD"))) {
// Запись в файловый лог
try (FileWriter fw = new FileWriter("/app/logs/application.log", true)) {
fw.write("DB connection established\n");
}
}
}
}


Почему это работает
:
- Переменные DB_URL и DB_PASSWORD передаются через process namespace, что безопаснее hardcode.
- Том app_logs изолирует логи от жизненного цикла контейнера — данные сохраняются после docker-compose down.
- JVM учитывает лимиты cgroups благодаря -XX:MaxRAMPercentage.



Best practices

1. Сети:
- Bridge — для локальной разработки,
- Overlay/CNI — для продакшена,
- Host — только для специфических задач.


2. Volumes:
- Named volumes — для БД и персистентных данных,
- Bind mounts — только для разработки (hot-reload).


3. Секреты:
- Всегда используйте Vault или Kubernetes Secrets в продакшене,
- Избегайте .env для секретов — он не шифруется.


4. Логирование:
- Настройте централизованное логирование (Fluentd + Elasticsearch),
- Используйте gelf или fluentd вместо json-file в продакшене.


5. JVM:
- Всегда ограничивайте память через -XX:MaxRAMPercentage,
- Проверяйте лимиты cgroups через cat /sys/fs/cgroup/memory/memory.limit_in_bytes.



#Java #middle #Docker #best
👍3🔥1
Что выведет код?

abstract class Animal050925 {
public Animal050925() {
System.out.print("Animal ");
makeSound();
}

abstract void makeSound();
}

class Dog050925 extends Animal050925 {
public Dog050925() {
System.out.print("Dog ");
}

void makeSound() {
System.out.print("Woof ");
}
}

public class Task050925 {
public static void main(String[] args) {
new Dog050925();
}
}


#Tasks
🤯2
Создал канал в сетке!

Присоединяйтесь! 🙂

https://set.ki/channel/35sLVoe
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Вопрос с собеседований

Что такое local inner class? 🤓

Ответ:

Local inner class
— класс, определенный внутри метода, с доступом к локальным переменным (если final или effectively final).

Пример:
void method() {
final int x = 10;
class Local {
void print() { System.out.println(x); }
}
new Local().print();
}

Полезен для временной логики в методе.


#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
🗓 История IT-технологий сегодня — 6 сентября


ℹ️ Кто родился в этот день

Влади́мир Алекса́ндрович Коте́льников (24 августа [6 сентября] 1908, Казань, Российская империя — 11 февраля 2005 года, Москва, Россия) — пионер теории информации и связи; теорема Котельникова (сэмплирование) — краеугольный камень цифровой обработки сигналов.

Лев Никола́евич Королёв (6 сентября 1926, Подольск — 5 января 2016, Москва) — советский и российский учёный в области радиофизики, радиотехники, электроники, информатики, радиоастрономии и криптографии, системный программист, развитие ПО и ОС для БЭСМ-6, становление программирования в СССР.


🌐 Знаковые события

1989 — из-за компьютерной ошибки 41 тыс. парижан получили письма, извещающие о том, что ими совершены убийства и грабежи вместо нарушений правил дорожного движения.


#Biography #Birth_Date #Events #06Сентября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Kubernetes

Зачем миру нужен Kubernetes?

Представьте, что вы строите небоскреб. У вас есть тысячи кирпичей (контейнеров), краны (серверы), рабочие (процессы). Без грамотного архитектора и прораба всё превратится в хаос: кирпичи будут лежать криво, краны простаивать, а рабочие — спорить, кто за что отвечает.

Kubernetes
(сокр. K8s) — это и есть тот самый «цифровой прораб», который автоматизирует развертывание, масштабирование и управление контейнеризированными приложениями. Но это не просто инструмент — это стандарт де-факто для оркестрации контейнеров в мире cloud-native разработки.


Почему это важно?
Когда приложения разбиваются на микросервисы (десятки или сотни независимых компонентов), ручное управление ими становится невозможным. Kubernetes решает эту проблему, превращая инфраструктуру в «самонастраивающуюся» систему, которая:
- Автоматически восстанавливает упавшие сервисы
- Масштабирует нагрузку «на лету»
- Обеспечивает непрерывную доставку кода без простоя



История: от внутренних систем Google к мировому стандарту

2014: Рождение в недрах Google
Kubernetes не появился на пустом месте. Его корни уходят в Borg — секретную систему оркестрации, которую Google использовал с 2003 года для управления своими сервисами (Поиск, Gmail, YouTube). Borg обрабатывал миллионы контейнеров ежедневно, но был закрыт для внешнего мира.

В 2014 году Google, совместно с Red Hat и Other, открыли исходный код Kubernetes (название происходит от греческого слова «κυβερνήτης» — «капитан, рулевой»). Это был не «облегченный Borg», а переработанная система с учетом опыта Google, но адаптированная для открытого использования.

2015: Передача в CNCF
Google передал Kubernetes Cloud Native Computing Foundation (CNCF) — некоммерческой организации, поддерживающей cloud-native технологии. Это был стратегический ход: чтобы система стала стандартом, она должна быть нейтральной и развиваться сообществом. Сегодня Kubernetes — самый успешный проект CNCF, с участием AWS, Microsoft, IBM и тысяч разработчиков.


Почему именно Kubernetes победил?

На момент появления существовали конкуренты (Docker Swarm, Mesos), но K8s выделялся:
- Глубокая проработка edge cases (опыт Google с миллиардами запросов)
- Декларативная модель (описывайте «что нужно», а не «как сделать»)
- Экосистема расширений (API можно расширять без изменения ядра)


Архитектура: как устроен «цифровой прораб»

Kubernetes работает по принципу control plane + data plane. Это как центр управления полетами (control plane) и самолеты (data plane).

Control Plane: «мозг» кластера

Располагается на master-нодах (хотя термин «master» устарел — теперь используется control plane node).

Состоит из:
1. API Server
Что это: Единственная точка входа для всех операций (развертывание, мониторинг).
Как работает: Принимает REST-запросы, проверяет права (через RBAC), записывает изменения в etcd.
Нюанс: Все компоненты взаимодействуют через API Server, даже сам Kubernetes. Это обеспечивает единую точку контроля и аудита.


2. etcd
Что это: Распределенное хранилище «состояния кластера» (какая нода работает, какие поды запущены).
Как работает: Хранит данные в виде ключ-значение. При изменении состояния (например, запуске нового пода) etcd рассылает события.
Нюанс: Требует нечетного числа нод (3, 5, 7) для кворума. Потеря большинства нод — катастрофа (split-brain).


3. Scheduler
Что это: «Распределитель задач». Решает, на какой ноде запустить новый под.
Как работает: Анализирует ресурсы нод (CPU, память), правила (taints/tolerations, affinity), выбирает оптимальный вариант.
Нюанс: Можно написать кастомный scheduler через API, если стандартный не подходит (например, для HPC-задач).



#Java #middle #on_request #Kubernetes
👍5
Архитектура Kubernetes

Kubernetes работает по принципу control plane + data plane. Это как центр управления полетами (control plane) и самолеты (data plane).


Control Plane: "мозг" кластера

Располагается на master-нодах (хотя термин «master» устарел — теперь используется control plane node).

Состоит из:
1. API Server
Что это: Единственная точка входа для всех операций (развертывание, мониторинг).
Как работает: Принимает REST-запросы, проверяет права (через RBAC), записывает изменения в etcd.
Нюанс: Все компоненты взаимодействуют через API Server, даже сам Kubernetes. Это обеспечивает единую точку контроля и аудита.


2. etcd
Что это: Распределенное хранилище «состояния кластера» (какая нода работает, какие поды запущены).
Как работает: Хранит данные в виде ключ-значение. При изменении состояния (например, запуске нового пода) etcd рассылает события.
Нюанс: Требует нечетного числа нод (3, 5, 7) для кворума. Потеря большинства нод — катастрофа (split-brain).


3. Scheduler
Что это: «Распределитель задач». Решает, на какой ноде запустить новый под.
Как работает: Анализирует ресурсы нод (CPU, память), правила (taints/tolerations, affinity), выбирает оптимальный вариант.
Нюанс: Можно написать кастомный scheduler через API, если стандартный не подходит (например, для HPC-задач).


4. Controller Manager
Что это: Набор «контроллеров», следящих за состоянием кластера.
Как работает: Например, Deployment Controller следит, чтобы количество запущенных подов соответствовало желаемому. Если под падает — пересоздает его.
Нюанс: Контроллеры работают по принципу reconciliation loop: постоянно сравнивают текущее состояние с желаемым.


5. Cloud Controller Manager (опционально)
Что это: Интеграция с облачными провайдерами (AWS, GCP).
Как работает: Управляет балансировщиками нагрузки, томами, сетями через API облака.



Data Plane: "рабочие руки"

Состоит из worker nodes (рабочих нод), где запускаются приложения:
1. Kubelet
Что это: Агент на каждой ноде.
Как работает: Получает задания от API Server, запускает/останавливает контейнеры через container runtime (Docker, containerd).
Нюанс: Kubelet не перезапускает контейнеры сам — это делают контроллеры (например, через Deployment).


2. Kube-proxy
Что это: Сетевой прокси.
Как работает: Обеспечивает доступ к сервисам через iptables/IPVS. Например, при обращении к my-service перенаправляет трафик на поды.
Нюанс: В режиме IPVS используется хэширование для балансировки, что эффективнее iptables при 10k+ сервисов.


3. Container Runtime
Что это: Движок для запуска контейнеров (Docker, containerd, CRI-O).
Нюанс: Kubernetes использует CRI (Container Runtime Interface) — абстрактный API, поэтому можно менять runtime без пересборки K8s.



#Java #middle #on_request #Kubernetes
👍5
Основные понятия Kubernetes

Cluster (кластер)
Что это: Группа нод (физических/виртуальных машин), управляющих приложениями.
Зачем: Объединяет ресурсы в единый «суперкомпьютер».
Нюанс: В production используют multi-zone кластеры для отказоустойчивости (ноды в разных зонах AZ).


Node (нода)
Что это: Отдельный сервер в кластере (worker или control plane).
Нюанс: Ноды могут иметь taints («отметки»), чтобы блокировать запуск подов (например, dedicated=gpu:NoSchedule).


Pod
Что это: Минимальная единица развертывания. Группа контейнеров, разделяющих сеть и томы.
Почему не один контейнер?
- Сторонние контейнеры (sidecar) для логирования, мониторинга
- Общая файловая система (например, веб-сервер + статика)

Нюанс: Pod не переживает перезагрузку ноды — его пересоздает контроллер.


Service
Что это: Абстракция для доступа к подам через стабильный IP/DNS.

Типы:
- ClusterIP (внутри кластера)
- NodePort (порт на каждой ноде)
- LoadBalancer (облачный балансировщик)

Нюанс: Service использует kube-proxy и EndpointSlice для балансировки. При 1000+ подах лучше включить EndpointSlice (уменьшает нагрузку на etcd).


Deployment
Что это: Управляет состоянием подов через ReplicaSet.

Как работает:
- Описывает желаемое состояние (например, 3 реплики)
- Обеспечивает rolling update (постепенное обновление без простоя)
- Поддерживает откат к предыдущей версии

Нюанс: Можно настроить readinessProbe (проверка готовности) и livenessProbe (проверка жизни) для корректного обновления.


ConfigMap и Secret
Что это: Хранение конфигурации и секретов.
Разница: Secret шифруется base64 (но не защищен по умолчанию — используйте etcd encryption или external secrets manager).
Нюанс: Избегайте монтирования ConfigMap как volume — при обновлении значения попадут в под с задержкой (до 1 минуты).



Как это работает: от команды до работающего приложения

1. Вы описываете желаемое состояние
Например, в YAML-манифесте Deployment указываете: replicas: 3, image: my-app:v2.

2. API Server сохраняет состояние в etcd
Все компоненты получают уведомление через watch API.

3. Scheduler назначает поды на ноды
Выбирает ноды с достаточными ресурсами, учитывая правила (например, nodeSelector: disk=ssd).

4. Kubelet запускает контейнеры
Через container runtime создает Pod с вашим приложением и sidecar-контейнерами (если есть).

5. Service направляет трафик
При обращении к my-service kube-proxy балансирует запросы между подами.

6. Контроллеры поддерживают стабильность
Если нода упала — Deployment Controller создаст новые поды на других нодах.


Ключевые особенности: почему это enterprise-ready

Декларативная модель
Вы говорите «каким должно быть приложение», а не «как его развернуть».

Например:
replicas: 5  # Не "запусти 5 экземпляров", а "должно быть 5 реплик"

Kubernetes сам решает, как достичь этого состояния (запустить новые поды, убить старые).

Self-healing
- Автоматический перезапуск упавших контейнеров
- Перемещение подов с нерабочих нод
- Проверка здоровья через liveness/readiness probes


Горизонтальное масштабирование
- HPA (Horizontal Pod Autoscaler): Масштабирует поды по CPU/memory или кастомным метрикам (например, RPS)
- Cluster Autoscaler: Добавляет/удаляет ноды в облаке при нехватке ресурсов


Организация конфигурации
- Namespaces: Изоляция сред (dev, prod)
- Resource Quotas: Ограничение ресурсов на namespace
- Network Policies: Контроль трафика между подами (как firewall)



Экосистема: Kubernetes как платформа

Kubernetes — не монолит, а ядро для построения платформы.


Расширения через:
- Operators: Управление stateful-приложениями (PostgreSQL, Kafka) как нативными объектами
- CRD (Custom Resource Definitions): Добавление своих типов объектов (например, CronTab)
- Helm: Управление версиями манифестов («пакетный менеджер для K8s»)
- Istio: Сервис-меш для продвинутой маршрутизации, мониторинга



#Java #middle #on_request #Kubernetes
👍6
🗓 История IT-технологий сегодня — 7 сентября


ℹ️ Кто родился в этот день

Алексе́й Я́ковлевич Червоне́нкис (7 сентября 1938 — 22 сентября 2014) — советский и российский учёный в области информатики, кандидат физико-математических наук, ведущий сотрудник Института проблем управления имени Трапезникова, профессор колледжа Royal Holloway Лондонского университета, соавтор теории VC-размерности, фундамент машинного обучения и обобщающей способности моделей.

Дэвид Паккард (англ. David Packard; 7 сентября 1912 — 26 марта 1996) — сооснователь Hewlett-Packard; один из архитекторов компьютерной индустрии Кремниевой долины.


🌐 Знаковые события

Не происходило вроде. Найдете - пишите в комментариях


#Biography #Birth_Date #Events #07Сентября
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Использование LLM в работе - мошенничество или обязательное условие?

Сегодня это тему не обсудил наверное только ленивый.
Наверное пришло и наше время поразмышлять об этом ☺️

Признаюсь сразу - давно и плотно использую разные LLM. Знаю много видов, периодически нахожу новые.
Но использую только бесплатные (жаль денег, за то, что можно найти бесплатно).
Использую ли в работе - конечно.

Давайте об этом и поговорим.


Много лет назад

Когда-то, когда трава была зеленее и в IT-шники брали за умение запустить IDE (по слухам), было принято в Java-проектах писать всё руками.
Все setter-ы, getter-ы, конструкторы и прочий boilerplate-код.

Но потом появился Lombok и пара аннотаций стало все это решать. И сегодня сложно встретить проект без его использования.

Уже тогда разработчики разделились на 2 лагеря. Естественно за и против.

Сегодня, даже большинство IDE по нажатию горячих клавиш сгенерирует Вам все что нужно. И да, если этим пользоваться без оглядки и понимания - это тоже может привести к проблемам как и Lombok.



И причем тут LLM?

Далее пойдет мнение автора, которое может отличаться от большинства, но ему пофиг 🙃.

Сейчас сообщество разработчиков практически делится на 2 лагеря:
1. Те, кто считает, что использование LLM - это смерть программиста как такового из-за усыхания мозга и в конце он станет рептилоидом 😂.

Тут я наверное не соглашусь. Ведь человечество и так преодолело барьер программных языков, перейдя к высокоабстрактным языкам. И ведь когда это начиналось, наверняка звучали прогнозы, что это разрушит будущее.
Но оно не разрушилось


2. Те, кто считает, что использование LLM - это то же самое, что Google или StackOverflow, только быстрее и глупее.
Отношу себя к этому лагерю.

Когда я начинал учить Java, LLM только проявлял себя и поэтому я учился по туториалам и ответам из StackOverflow. Но сейчас, чтобы получить ответ на распространенный вопрос - достаточно написать LLM и вуаля.

НО! Важно понимать и знать, что как и на StackOverflow, выбирая из ответов самый залайканый или подходящий к ситуации, никто не давал гарантий, что он единственно правильный и обязательно будет работать.
Или, что вставив его в свой код, пропадет нужда достичь понимания как он работает.

Так и LLM легко напишет Вам методы которых не существует. Или даст ответ который вы не понимаете.


И что, не использовать его из-за этого? (Это как удалить телеграм, ведь где-то, кого-то обманули через него 😏)


В целом, подытоживая свой поток мыслей, считаю:
- что LLM сегодня для меня, это очень востребованный и важный инструмент самообучения, поиска и помощи.
- что игнорировать его просто глупо, ведь программист точно должен смотреть в будущее, а не в прошлое.



Риски использования LLM

1. Как я и сказал выше - шанс галлюцинаций, будьте внимательны и перепроверяйте информацию.
2. Юридические риски: лицензии, утечка кода в LLM → нарушение NDA.
3. Когнитивные риски: если использовать только как "копипасту", можно забыть как учиться.



Как относиться к использованию LLM в работе

На мой скромный взгляд, нужно относиться как к молотку на стройке.
Если нужно забить гвоздь - это незаменимый и важный помощник. И человек забивающий гвозди головой, будет выглядеть как минимум странно.
Другое дело, когда надо, к примеру, разрезать стекло.
Если бездумно использовать молоток, вы совершенно точно просто все испортите. Но при тонком знании и понимании процесса, прямых руках и капельке удачи - все вполне реализуемо.

Так и с LLM.

Но решать в итоге, конечно, Вам
✌️


А что вы думаете об этом?


Понравилась статья - поделись с другом, позови его на канал и будет тебе моя благодарность 🤝

😎

#motivation
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6