pvc должен быть менее чем pv

опять же это всё верно для какого нить локального провиженера. для более интеллектуальных случаев вам при наличии pvc провиженер создаст pv нужного размера

опять же это всё верно для какого нить локального провиженера. для более интеллектуальных случаев вам при наличии pvc провиженер создаст pv нужного размера

А что такое локальный провижнер? Некоторый сторадж с преднарезанными PV без объектного хранилища?

опять же это всё верно для какого нить локального провиженера. для более интеллектуальных случаев вам при наличии pvc провиженер создаст pv нужного размера

Ну смотри, у меня задача: создать темплейты для нескольких небольших тестовых однонодовых кластеров. И под базу нужно сделать волюм. Я же правильно понимаю, что я как-то вот так создаю PV: kind: PersistentVolume apiVersion: v1 metadata: name: postgres-pv-volume labels: type: local app: postgres spec: storageClassName: manual capacity: storage: 5Gi accessModes: - ReadWriteOnce hostPath: path: "/mnt/data" Вот как-то так PVC: apiVersion: v1 kind: "PersistentVolumeClaim" metadata: name: "db-data" spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi storageClassName: manual И потом в спеке контейнера прифигачиваю к нему volume: spec: containers: - image: postgres:9.6 name: dbpostgres ports: - containerPort: 5432 volumeMounts: - name: postgres-db-data mountPath: /var/lib/postgresql volumes: - name: postgres-db-data persistentVolumeClaim: claimName: db-data

Сорри АФК

Коллеги, а вы когда в кубер выкатываетесь, в джобе для подключения просто конфиг кластера прокидываете через переменную, а потом echo $KUBE_CONFIG > .kube/confg и по сути оно должно потом стучаться сразу в нужный кластер?

ребят как в ингрес можно сделать чтобы когда указываешь что /api должен смотреть в определенный сервис, то сервис тоже отадавал данные по урлу /api а не из /?

Коллеги, а вы когда в кубер выкатываетесь, в джобе для подключения просто конфиг кластера прокидываете через переменную, а потом echo $KUBE_CONFIG > .kube/confg и по сути оно должно потом стучаться сразу в нужный кластер?

я бы в кавычки взял

можно явно указывать kubeconfig в аргументах командной строки (* зависит от применяемой тулзы, конечно) или в переменных окружения, зачем эти пляски с копированием

Лол

Здравствуйте, посоветуйте интересных докладчиков по DevOps на https://devconf.ru/ru/offers/DevOps

Коллеги, а вы когда в кубер выкатываетесь, в джобе для подключения просто конфиг кластера прокидываете через переменную, а потом echo $KUBE_CONFIG > .kube/confg и по сути оно должно потом стучаться сразу в нужный кластер?

вообще я вот так вот накостылил: stages: - modify-resource modify-resource: image: madfromplay/git-base:3 services: - docker:dind only: - triggers stage: modify-resource tags: - build script: - mkdir ~/.ssh/ - mkdir ~/.kube/ - echo $priv_key | base64 -d > ~/.ssh/id_rsa - echo $pub_key | base64 -d > ~/.ssh/id_rsa.pub - echo $kubeconfig | base64 -d > ~/.kube/config - chmod 600 ~/.ssh/id_rsa - ssh-keyscan -t rsa <my_repo> >> ~/.ssh/known_hosts - cd /tmp/ - git clone git@<my_repo>/k8s.git - cd k8s - /bin/sh controller-updater.sh - kubectl apply -f $PROJECT_NAME/$PROJECT_NAME-controller.yaml - git commit -m "automation deployment of $PROJECT_NAME" -a - git branch -a - git push git@<my_repo>/k8s.git

в башовом скрипте sed который версию перепиливает

Здравствуйте, посоветуйте интересных докладчиков по DevOps на https://devconf.ru/ru/offers/DevOps

@kvaps и @sintezoid

@kvaps и @sintezoid

спасибо

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

есть

самый простой - находить по аннотациям и удалять

хм. написать скрипт, парсящий ямлы деплойментов и выдирающий из аннотаций?

а если ямлы удалили вместе с деплойментом - то или руками искать, или самому скриптом парсить ямлы имеющихся деплойментов, строить структуру существующих связей и удалять то что в нее не вошло?

делайте по NS на дейплоймент и грохайте NS. Или используйте helm

хм. написать скрипт, парсящий ямлы деплойментов и выдирающий из аннотаций?

по лейблам ты можешь это сделать прямо через --selector

хм. написать скрипт, парсящий ямлы деплойментов и выдирающий из аннотаций?

Вешать на деплоймент lable а потом селектором брать нужный

Коллеги, а вы когда в кубер выкатываетесь, в джобе для подключения просто конфиг кластера прокидываете через переменную, а потом echo $KUBE_CONFIG > .kube/confg и по сути оно должно потом стучаться сразу в нужный кластер?

да. или через переменную типа file и потом kubectl apply --kubeconfig=$KUBE_CONFIG_FILE

Вообще это best practicies, заполненная метадата облегчает жизнь

да. или через переменную типа file и потом kubectl apply --kubeconfig=$KUBE_CONFIG_FILE

О точно! файл!

так вот зачем все эти лэйблы и прочая фигня… на будущее учту. а сейчас с существующим кластером разобраться как-то надо. спасибо!

так вот зачем все эти лэйблы и прочая фигня… на будущее учту. а сейчас с существующим кластером разобраться как-то надо. спасибо!

метаданные

эта "фигня" называется метаданные

понятно. просто похоже в существующем кластере это игнорировалось, поскольку не влияло на работу непосредственно.

а как сервисы находят поды прямо щас?

и как ингрессы находят сервисы

Дмитрий Столяров? :)

что за фигня! Я поставлю прод реди за день!

что за фигня! Я поставлю прод реди за день!

С нуля, включая ноль знаний про него?

С нуля, включая ноль знаний про него?

в цитате этого условия нет!

а как сервисы находят поды прямо щас?

смотрю примеры ямлов, в метадате в основном пара ключей - осмысленный нэйм и нэймспейс default

Я не большой девопсщик, более глубоко не скажу

Я не большой девопсщик, более глубоко не скажу

Д - девопсщсщсшщсщик 🤣

Дмитрий Столяров? :)

Он

@distol ты мем

Это плохо или хорошо?

Не плохо и не хорошо, просто интересно

Легенда

Кто-нибудь уже пробовал куб в яндекс облако?

Кто-нибудь уже пробовал куб в яндекс облако?

Это вброс ? 😉

Это вброс ? 😉

*пошел за попкорном*

да нормальный же вопрос. с инженерной точки зрения потрогать его интересно, но не более того

Кто-нибудь уже пробовал куб в яндекс облако?

Пробовали. Посмотреть новичку и задеплоить хелпеврибади хватит

На все наши запроосы тп ответила - все будет, функционал развиваетмя

На все наши запроосы тп ответила - все будет, функционал развиваетмя

А чего вам не хватает, кроме интеграции с тамошним lb?

Psp

ммм, managed куб без psp. Я как раз себе бесплатный хостинг подыскивал :)

Есть подобное, но для формата крио? https://github.com/fluent/fluentd-kubernetes-daemonset

Есть подобное, но для формата крио? https://github.com/fluent/fluentd-kubernetes-daemonset

разворачивать crio демонсетом?

И что же будет запускать поды с крио? Другой рантайм?

собирать логи в том формате, в котором пишет крио.

Просто не хочется руками регекспы писать для флюента. (По ссылке выше оно заточено на докеровский жсоновый драйвер)

собирать логи в том формате, в котором пишет крио.

свежее крио умеет писать в journald

логи контейнеров?

логи контейнеров?

https://asciinema.org/a/236235

https://asciinema.org/a/236235

root@localhost

свежее крио умеет писать в journald

Ооо, вот это прям оч.хорошо! Настанет день и я попробую снова

Жахнул кучу комплитед и эвиктед подов, один нэймспейс в котором не было ни одного пода (надеюсь, никакие другие ресурсы не были на его завязаны), теперь хочу пожахать неиспользуемые сервисы. Но! На этом кластере крутится прод, и очень не хочется жахнуть лишнее. Поэтому хочу уточнить - если у сервиса в селекторе есть пара ключей/значений, а get deployment -l по каждому из них отдельно не выдают никакой деплоймент - значит что сервис не используется никем и его можно жахать? независимо от типа сервиса?

встречный вопрос: кто-нибудь использует CRI-O на debian-based?

Жахнул кучу комплитед и эвиктед подов, один нэймспейс в котором не было ни одного пода (надеюсь, никакие другие ресурсы не были на его завязаны), теперь хочу пожахать неиспользуемые сервисы. Но! На этом кластере крутится прод, и очень не хочется жахнуть лишнее. Поэтому хочу уточнить - если у сервиса в селекторе есть пара ключей/значений, а get deployment -l по каждому из них отдельно не выдают никакой деплоймент - значит что сервис не используется никем и его можно жахать? независимо от типа сервиса?

создай новый кластер, перенеси туда прод, грохни старый кластер

это мне еще страшнее будет сейчас делать ) наверное попробую удалять сервисы по одному. еще как-то потом с персистент вольюмами надо разбираться

заводить новый кластер страшно?

а ломать прод не зная последствий не страшно?

ну переносить прод так и так страшно )

да вроде не очень

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

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

а прод в кластере из воздуха появился или есть какие-то ci/cd инструменты?

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

а апплай применялся на воздух?

Потом часть удалялась, а часть связанных не удалялась… А теперь мне партия приказала все это причесать

или на какие-то файлы?

откуда удалялась? из репозитория?

подозреваю kubectl delete