Ответ
Вопрос о "таблицах" в Kubernetes некорректен, так как Kubernetes — это оркестратор контейнеров, а не СУБД. Он оперирует ресурсами (resources), а не таблицами.
На последнем проекте мы активно использовали следующие типы ресурсов Kubernetes для конфигурации и управления приложениями:
- ConfigMaps и Secrets: для хранения конфигурации и чувствительных данных (пароли, токены) отдельно от образов приложений.
- Deployments/StatefulSets: для декларативного описания и развертывания рабочих нагрузок (пода).
- Services и Ingress: для обеспечения сетевого доступа к приложениям.
- PersistentVolumeClaims (PVC): для динамического предоставления постоянного хранилища (например, из облачного блочного хранилища).
- Custom Resource Definitions (CRD): для расширения API Kubernetes под нужды проекта (например, для операторов).
Пример манифеста для ConfigMap:
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
application.properties: |
server.port=8080
logging.level.root=INFOИспользование этих ресурсов позволяет соблюдать принцип Immutable Infrastructure и практики GitOps, храня все конфигурации в репозитории.
Ответ 18+ 🔞
Да ты посмотри, какие вопросы пошли! "Таблицы в кубере" — это ж надо додуматься, блядь! Это ж не база данных, ёпта, а оркестратор! Он не таблицами рулит, а ресурсами, вот этими самыми, как их... объектами API, короче.
На прошлом проекте мы там так накрутили с этими ресурсами, что до сих пор вспоминаем. Как с утра пораньше:
- ConfigMaps да Secrets: Ну, классика ж, блядь. Всякую хуйню типа настроек портов или, прости господи, паролей от базы — отдельно от самого приложения храним. Чтобы не пересобирать образ, если просто конфиг поменялся. Гениально же, в рот меня чих-пых!
- Deployments/StatefulSets: Ну это вообще основа, без этого нихуя. Хочешь задеплоить десять копий своего сервиса — пишешь один файлик, и он сам всё сделает. А StatefulSets — это когда тебе важно, чтобы у каждой копии имя своё было и хранилище персональное, для всяких баз данных, например. Умная штука, блядь.
- Services с Ingress'ами: Ну как без этого, сука? Твои десять копий сервиса где-то там в кластере болтаются, а как к ним обращаться-то? Service — он им единую точку входа создаёт, а Ingress — это уже чтобы снаружи, из интернета, можно было зайти по красивому URL. Без этого — просто набор подав, нихуя не связанных.
- PersistentVolumeClaims (PVC): А это, блядь, для жадных! Когда твоему приложению мало памяти в контейнере, а надо что-то на постоянку сохранять. Ты пишешь заявку: "Дай мне 10 гигов быстрого хранилища", а кубер сам где-нибудь в облаке это хранилище организует и прицепит. Волшебство, ёпта!
- Custom Resource Definitions (CRD): А вот это уже для продвинутых шаманов, когда стандартных ресурсов не хватает. Хочешь свой собственный тип ресурса, типа
SuperDatabase? Пожалуйста, опиши его через CRD, и он появится в API кубера наравне с Pod'ами! Мы для своих операторов такое делали — мощная тема, блядь.
И вся эта хуйня, понимаешь, позволяет жить по правильным понятиям — Immutable Infrastructure. Не лезешь ты по SSH в контейнер ручками конфиги менять, а просто меняешь манифест в гите и применяешь его. GitOps, все дела. Красота!
Вот, смотри, как простой ConfigMap выглядит, чтоб ты понимал масштаб:
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
application.properties: |
server.port=8080
logging.level.root=INFOНаписал такой файлик, применил kubectl apply -f, и всё, блядь, конфиг внутри кластера лежит. Потом его в под как файл или переменные окружения засунул — и никаких проблем. Всё прозрачно, всё версионируется. Не жизнь, а малина!
Так что запомни: в кубере не таблицы, а ресурсы. Иначе опозоришься на собеседовании, как последний... ну, в общем, не делай так.