Да про пробл с кубом ничего не писал же

и иногда кластер падает(

Да про пробл с кубом ничего не писал же

Да, но судя по уровню драмы с цепхом мы бы могли в теории узнать об инфернальном кластере

там даже с доступом по ссш както всё ебово. рвёт постоянно и опять не пускает

тыркнешь в телегу — он чото делает и пускает

но цеф из почти руин мне понравилось поднимать

до этого был какой-то еблан который в панике вынимал и вставлял диски

та анфаунды и всё такое

ладно хоть додумался не протирать вынутые диски

по одному вставляли и сливали с них

в итоге этот дебил восстановил бекап мониторов.

и окончательно добил весь кластер

дебил блять

Отсортируй pv по времени маунта и удаляй их

Отсортируй pv по времени маунта и удаляй их

А вот как туда первым был залит постгрес без репликации и без бэкапов с жизненно нужными данными?

А вот как туда первым был залит постгрес без репликации и без бэкапов с жизненно нужными данными?

И не был смаунчен? Штош тогда

есть куча пвц которые не открыты в данный момент

А что в твоем понимании "нужные" и "ненужные" данные, что конкретно ты хочешь снести из ceph? kubectl get pvc --all-namespaces - вот это обычно нужные данные, т.к. ненужные pvc обычно удаляют, в след за ними удаляются и pv

можно считать что это мусор ?

можно считать что это мусор ?

далеко не факт

А что в твоем понимании "нужные" и "ненужные" данные, что конкретно ты хочешь снести из ceph? kubectl get pvc --all-namespaces - вот это обычно нужные данные, т.к. ненужные pvc обычно удаляют, в след за ними удаляются и pv

а эти ненужные пвц надо руками удалять или оно само их грохает ?

руками

зачем так больно

😐а ведь мне скоро такую же балду как у него возводить.....

зачем так больно

на самом деле нет, если не допускать появления однозначно ненужных pvc, что, прямо скажем, несложно

пошто чувак, которому ты цеф чинишь, сам ненужные pvc с rbd не подчистит?

зачем так больно

kubectl delete pvc --allхаха

пошто чувак, которому ты цеф чинишь, сам ненужные pvc с rbd не подчистит?

о ходу не шарит

предположу что там хрычезарплаты

и наняли какогото нубаса

который очкует

kubectl delete pvc --allхаха

Не надо так, он же два дня гадить тут будет

а до него какието был тупые, но активные

Не надо так, он же два дня гадить тут будет

блять, но я не еблан же чтобы напрямую советы из чата использовать

а то вы тут нахрычуете

о ходу не шарит

ну а кто шарить-то вместо него будет? ладно, цеф поправить, но надо же быть в курсе, что у тебя там работает-то вообще и зачем

Ты и так все сломаешь и на нас будешь сваливать вину, что тут гадать

Ты и так все сломаешь и на нас будешь сваливать вину, что тут гадать

нет, вы меня с кем-то путаете

ну для начала определи критерий ненужности

у них кластера минимум 3 мастера и etcd вообще вынесен хз куда, для подстраховки

примерно вот такой статус

вообще, у меня вот 177 pvc на ebs создано, но там большинство на стейджинг-окружения приходится, некоторые из которых автоматически не снеслись из-за забытых девелоперами пулл-реквестов, при закрытии которых они должны были сдохнуть. может, у него там похожая ситуация?

у них кластера минимум 3 мастера и etcd вообще вынесен хз куда, для подстраховки

а что с этим не так?

вообще, у меня вот 177 pvc на ebs создано, но там большинство на стейджинг-окружения приходится, некоторые из которых автоматически не снеслись из-за забытых девелоперами пулл-реквестов, при закрытии которых они должны были сдохнуть. может, у него там похожая ситуация?

может. я хз

я прост хочу почистить данные в цефе чтобы побыстрее ребелансилось

а что с этим не так?

да я тут выше угарал, что у них мб кластер не хуже цефа настроен

ну для начала определи критерий ненужности

никто за тебя этого не сделает

ну блин. вангую что данные от остановленных (или даже удалённых) контейнеров

вообще, у меня вот 177 pvc на ebs создано, но там большинство на стейджинг-окружения приходится, некоторые из которых автоматически не снеслись из-за забытых девелоперами пулл-реквестов, при закрытии которых они должны были сдохнуть. может, у него там похожая ситуация?

У нас для от такой беды волюмы помечаются аннотацией expirationDate - и бегает pruner который их пытается удалить, если они не Bound

У нас для от такой беды волюмы помечаются аннотацией expirationDate - и бегает pruner который их пытается удалить, если они не Bound

Проблема в том, что они bound, потому что само тестовое окружение никуда не девается. Я периодически просто закрываю особо протухшие PR с уведомлением девелоперов. захотят - переоткроют, делов-то. Надо бы по такому же принципу бота написать.

Привет всем. есть кто юзает EKS ? не было проблем с подвисанием нод ?

или что может быть не так ? ноды в статусе ready. но не один под не поднимается, в дескрайбе пишет 0\3 nodes are available

или что может быть не так ? ноды в статусе ready. но не один под не поднимается, в дескрайбе пишет 0\3 nodes are available

я чот подозреваю, что это не все, что написано в дескрайбе

[18:49:36] ole $ kubectl describe pod/nginx-64f497f8fd-zhvs2 Name: nginx-64f497f8fd-zhvs2 Namespace: default Priority: 0 PriorityClassName: <none> Node: <none> Labels: pod-template-hash=2090539498 run=nginx Annotations: <none> Status: Pending IP: Controlled By: ReplicaSet/nginx-64f497f8fd Containers: nginx: Image: nginx Port: <none> Host Port: <none> Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-qcw97 (ro) Conditions: Type Status PodScheduled False Volumes: default-token-qcw97: Type: Secret (a volume populated by a Secret) SecretName: default-token-qcw97 Optional: false QoS Class: BestEffort Node-Selectors: <none> Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 68s (x271 over 16m) default-scheduler 0/3 nodes are available: 3 Insufficient pods.

А какие ноды?

Тип инстансов

Так-то, емнип, это значит, что проблемы с лимитами по количеству подов на ноду

мелкие, для тестов t2.micro

не знал про лимиты, это у ЕКС как у сервиса ?

или у ЕС2 ?

Теперь дескрайб нод надо бы.

Там небось авсный плагин, который сеть реализует через eni, а их на t2 как-то совсем мало можно повесить.

не знал про лимиты, это у ЕКС как у сервиса ?

Скорее как у сервиса. Понимаш, там у них свой CNI плагин и каждому поду свой сетевой интерфейс (ENI) выдается. А количество приаттаченых сетевых интерфейсов зависит от типа инстанса и в высших своих проявлениях равен вроде 17 или около того

https://pastebin.com/5inMa5FQ

чтоб не сорить

чтоб не сорить

pods: 4

в секции capacity. у тебя на каждой ноде kube-proxy, еще есть пара-тройка демонсетов наверняка...

так, а получается только увеличив инстанс можно увеличить кол-во подов ?

Похоже на то

Жесть

тоесть можно только 17 eni реализовать на eks ?

Ну тут пишут, что EKS дает возможность поставить другой cni

погуглю спасибо

да и t2.micro и так на минимальные требования куба не подходят никак

да я тестирую )

да я тестирую )

https://kubernetes.io/docs/setup/independent/install-kubeadm/#before-you-begin

да понятно))) я тестирую именно екс и смотрю есть ли в нем смысл))

тоесть можно только 17 eni реализовать на eks ?

На каждый воркер можно определённое число eni навесить, чем больше инстанс, и чем больше таких инстансов, тем больше eni в сумме можно получить -> тем больше подов запустить.