Nvme не похоже на медленные диски)

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

Понял)

у нас на других серверах магнитные в таком же пуле дают больше iops

Теперь понятно почему хецнер столько стоит)

у хетцнера я облако не покупал, только железку и там постоянно приходилось менять диски, потому что просишь замену из-за того, что сыпется, а они тебе меняют на б/у

который через какое-то время тоже сыпется

У нас тоже пару раз диски у хецнера дохли

На овх пока все норм

Порядка 130 серверов у нас там

смотришь в smart свежепоменяного диска, а там 10000 часов аптайма

У OVH все ssd intel

А у хецнера вендор какой?

На скрине unknown

У нас нульцевый такой же тошиба на этом же сервере и 3 месяца не прожил, контроллер умер походу

А вижу

Кстати micron на их AMD Ryzen 1700 работают почти как эти NVME даже немного стабильнее

Короче надо сервера покупать только с дисками Data Center Series:)

Порядка 130 серверов у нас там

а у меня один для персональных нужд, диски менялись раз 6-8 за 4 года

В овх?

Хз, у нас иопсов не так много, кроме серваков баз

Их штук 10

О, в моем родном городе конференция по кубу)

Приятно)

не, не овх

продублирую сюда

и ещё непонятно где брать разницу между requests и limit

в кубе манифесте у меня вписано resources: limits: cpu: 100m memory: 1Gi requests: cpu: 50m memory: 512Mi

лимит попадает в лимиты контейнера

а requests?

requests это ж сколько нужно свободных ресурсов на ноде чтобы под туда зашедулился

и в метриках его нету

у нас какой-то дикий оверпровижнинг и кажется начальник считает что это ок

1274.50% на одной из нод

@Andorka А в каких метриках нет requests?

ни в каких не нашёл

дашборд же показывает эту инфу для нод

да наверняка где-то есть метрика

но я найти не могу

Кто-нибудь внедрял себе BOSH инструментарий?

И если да, то насколько оно в действительности удобно (а не оверхед)?

коллеги, а может кто-нибудь знает, почему для пользователя в k8s cli доступные действия и неймспейсы видны, а через dashboard с авторизацией через token - не видно неймспейсов?

аккаунту, от которого токен, не хватает прав?

можно забайндить акканут борды на cluster-admin роль, тогда будет хватать прав: apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: kubernetes-dashboard roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: kubernetes-dashboard namespace: kube-system

можно как-то сделать, чтобы при любом рестарте пода новый не стартовал пока старый не остановится окончательно?

в рамках деплоймента?

Пипл, как лучше юзать кубернетс кластер под гитлаб раннеры - по DinD модели или пробрасывать сокет докердемона с родительской машины?

шо то шо то требует сокет в контейнер же

продолжая странное:

что за хрень, метрика sum(container_spec_cpu_quota{id!="/"}) by (instance) есть для 4 нод из 7-и

при этом sum(container_spec_cpu_period{id!="/"}) by (instance) есть для всех 7-и

версии ядер, докеров и куберов одинаковые

в рамках деплоймента?

да

можно как-то сделать, чтобы при любом рестарте пода новый не стартовал пока старый не остановится окончательно?

я сначала прочел как "при обновлении новый не стартовал пока старый не остановился". но написано как то по другому

по идее вот так: spec: replicas: 1 strategy: rollingUpdate: maxSurge: 0 maxUnavailable: 1 type: RollingUpdateт.е. при 1 реплике он не будет создавать новую версию maxSurge: 0 пока не убьет старую maxUnavailable: 1

Не проще spec: replicas: 1 strategy: type: Recreate?

Не проще spec: replicas: 1 strategy: type: Recreate?

+

спасибо

кстати да

только вот в обоих случаях будет даунтайм - это действительно так задумано?

ну и что еще хуже, если новая версия не стартует по какой-то причине то старой версии уже нет

вроде это требование и было в изначальном запросе

Вопрос про деградацию кластера при падении 1 из 3 нод etcd.

Схема такая node1 - k8s-master, etcd node2 - k8s worker, etcd node3 - k8s worker, etcd node4 - k8s-master node5 - k8s-master Кластер из трех etcd стоит отдельным сервисом вне кубернета и докера. Эти три etcd сервера прописаны через запятую в --etcd-servers= На мастерах кубы стоит keepalived, а в конфигмапе kube-proxy прописан плавающий айпи. При падении любой ноды etcd кластера (даже не той которая совмещает роль мастера кубернета и etcd ноды) залипают отдельные ноды кубернета. При этом сам кластер etcd работоспособен и доступен на запись/чтение. А на проблемных нодах в логах апи-подов появляются сообщения о таймауте: E0305 13:32:57.551857 1 available_controller.go:295] v1beta1.admissionregistration.k8s.io failed with: Timeout: request did not complete within allowed duration E0305 13:32:57.552320 1 available_controller.go:295] v1beta1.certificates.k8s.io failed with: Timeout: request did not complete within allowed duration E0305 13:32:57.552437 1 available_controller.go:295] v1.autoscaling failed with: Timeout: request did not complete within allowed duration При этом "здоровые" ноды удаляют/разворачивают новые поды и нормально функционируют. Со временем такая проблема возникает на другой ноде, а на той что сбоила приходит в норму. И так пока не запустить все ноды etcd.

можно как-то сделать, чтобы у подов в деплойменте (не в statefulset) при рестарте имена не менялись?

StatefulSet

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

StatefulSet

ивиняюсь, исправил, забыл сразу дописать

ну переделать деплоймент в стейтфулсет - недолго

имхо

если конечно есть такая возможность

дело не во времени

можно как-то сделать, чтобы у подов в деплойменте (не в statefulset) при рестарте имена не менялись?

https://stackoverflow.com/questions/34609572/is-it-possible-to-set-a-hostname-in-a-kubernetes-replication-controller

но если можно без этого обойтись то я тоже за сервис

можно как-то сделать, чтобы у подов в деплойменте (не в statefulset) при рестарте имена не менялись?

Ну проектно нет. Под формируемыей деплоем имеет рандомное имя by design

на SO мужики говорят можно

SO ?

вон выше ссылка