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

тут у всех такая проблема была.

Приветствую! Кто-нибудь в курсе, что там поломали в helm-репозитории у kube-prometheus? Все работало еще пару недель назад, теперь запуск команды helm upgrade -i kube-prometheus coreos/kube-prometheus --namespace {{ monitoring_namespace }} выдает портянку ошибку "Error: validation failed: [unable to recognize \"\": no matches for kind \"Alertmanager\" in version \"monitoring.coreos.com/v1alpha1\", unable to recognize \"\": no matches for kind \"Prometheus\" in version \"monitoring.coreos.com/v1alpha1\", unable to recognize \"\": no matches for kind \"PrometheusRule\" in version \"monitoring.coreos.com/v1\", unable to recognize \"\": no matches for kind \"PrometheusRule\" in version \"monitoring.coreos.com/v1\", ....

+ такая же пролблема

Это платиновый вопрос

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

)

блин, плохо (

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

Куб и даш по умолчанию не создает админского сервиса-юзера. Народ это фрустирует)

Это платиновый вопрос

а что значит платиновый?

там же rbac надо настраивать

и это все описано же. вроде

у меня по крайней мере не было проблем

по докам пишут, что надо какаой-то конфиг /etc/kubernetes/admin.conf стравить вебморде, но что-то я его копировать не могу ( на моей машине нет куба. Всё настроил на отдельном сервере, рядом с Proxmox

там же rbac надо настраивать

Надо, написано, но вопрос этот постоянный и неизбывный

там же rbac надо настраивать

ммм

Oct 19 13:54:54 kube-master1 kubelet[1533]: I1019 13:54:54.000727 1533 kuberuntime_manager.go:757] checking backoff for container "kube-controller-manager" in pod "kube-controller-manager-kube-master1.domain.com_kube-system(3687c17433749fed6789102dcc2ddd2c)" Oct 19 13:54:54 kube-master1 kubelet[1533]: I1019 13:54:54.000906 1533 kuberuntime_manager.go:767] Back-off 1m20s restarting failed container=kube-controller-manager pod=kube-controller-manager-kube-master1.domain.com_kube-system(3687c17433749fed6789102dcc2ddd2c) Oct 19 13:54:54 kube-master1 kubelet[1533]: E1019 13:54:54.000948 1533 pod_workers.go:186] Error syncing pod 3687c17433749fed6789102dcc2ddd2c ("kube-controller-manager-kube-master1.domain.com_kube-system(3687c17433749fed6789102dcc2ddd2c)"), skipping: failed to "StartContainer" for "kube-controller-manager" with CrashLoopBackOff: "Back-off 1m20s restarting failed container=kube-controller-manager pod=kube-controller-manager-kube-master1.domain.com_kube-system(3687c17433749fed6789102dcc2ddd2c)" помогите запустить эту поду плиз

тут у всех такая проблема была.

как решили?

ммм

короче делай раз kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml делай два apiVersion: v1 kind: ServiceAccount metadata: name: admin-user namespace: kube-system делай три apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: admin-user roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: admin-user namespace: kube-system

короче делай раз kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml делай два apiVersion: v1 kind: ServiceAccount metadata: name: admin-user namespace: kube-system делай три apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: admin-user roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: admin-user namespace: kube-system

два и три это что? куда это?

короче делай раз kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml делай два apiVersion: v1 kind: ServiceAccount metadata: name: admin-user namespace: kube-system делай три apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: admin-user roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: admin-user namespace: kube-system

там еще 4 было, где из секрета токен достать)

верно

kubectl -n kube-system get secret

как решили?

присоединяюсь к вопросу - как теперь prometheus через helm завести?

kubectl -n kube-system get secret

это делал ) прав было мало

им ишу вообще такой создавал кто-нибудь?

судя по всему https://github.com/coreos/prometheus-operator/issues/2025

это делал ) прав было мало

два и три это файлы. kuberctl create -f

создастя сервис аккаунт и сбиндится с ролью

а потом уже надо секрет доставать с токеном

Задачу поставили, поднять инраструктуру облака. Пытаюсь вот у себя локально это дело провести. Как же всё это долго и сложно -_- Нужно проверить, как к8с будет работать с вендовыми контейнерами/сервисами/нодами (потому что нужна поддержка сервисов онли для венды) Еле как поднял куб кластер. Задеплоил дешборд. Но не могу в него зайти не под анонимом ((

#платиновые_треды_k8s

а называть как? рандомно?

ну от имени файла - содержимое не зависит

ну от имени файла - содержимое не зависит

а куда желательно это сохранять? в /etc/kubernetes?

неа

вообще без разницы

~ тогда

язабан

интересно какой опыт у mail.ru в обновлениях, оно ж только недавно вышло в паблик

Приветствую! Кто-нибудь в курсе, что там поломали в helm-репозитории у kube-prometheus? Все работало еще пару недель назад, теперь запуск команды helm upgrade -i kube-prometheus coreos/kube-prometheus --namespace {{ monitoring_namespace }} выдает портянку ошибку "Error: validation failed: [unable to recognize \"\": no matches for kind \"Alertmanager\" in version \"monitoring.coreos.com/v1alpha1\", unable to recognize \"\": no matches for kind \"Prometheus\" in version \"monitoring.coreos.com/v1alpha1\", unable to recognize \"\": no matches for kind \"PrometheusRule\" in version \"monitoring.coreos.com/v1\", unable to recognize \"\": no matches for kind \"PrometheusRule\" in version \"monitoring.coreos.com/v1\", ....

CRD неприменились (может просто аписервер не успел срегаировать ещё). Попробуйте передеплоить поверх. Ха! Шуткую, не получится ибо #helmговно

будет ли трансляция?

да, будет

круть, спасибо

да, будет

Где? :)

На youtube. Мы скинем ссылку на трансляцию в чат и на страницу регистрации в день события

Я б на канал просто подписался )

CRD неприменились (может просто аписервер не успел срегаировать ещё). Попробуйте передеплоить поверх. Ха! Шуткую, не получится ибо #helmговно

так особо альтернатив хельму не вижу

не apply же в конце-концов

Всё, посоны, сделал. Спасибо! ?

Жаль, что не получилось всё таки в контейнере LXC всё это дело провернуть (

не apply же в конце-концов

helm template | kubectl apply -f -

а как чистить потом

helm purge name

так оно ведь не через helm ставиться или я что-то не понял

> helm template | kubectl apply -f -

а как чистить потом

--prune

не apply же в конце-концов

Поверь, apply порой надежней? Хотя как советуют выше, если нужно генерировать темплейты из шаблона то helm-template рулит

не apply же в конце-концов

почему?

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

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

Я обычно replace использую, и или apply —force .

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

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

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

через хельм лучше крит не ставить, можно типа прометеуса и ингресса

очередной апргейд - может сломать(

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

Еще похуже) Когда начинается обновление релиза Helm выдает: Error: UPGRADE FAILED: a released named dev-users is in use, cannot re-use a name that is still in use И статус релиза становится: PENDING_UPGRADE. Причем Helm создает configmap с версией релиза которая зафейлилась, и начинает и уходит в статус PENDING_UPGRADE, и на этом все) В итоге приходится править этот configmap руками и перезапускать стадию деплоя. После этого все норм

Кто-то работает с windows контейнерами?

Как синхронизируете версии у разработчиков и на продакшене? Сложности при апгрейдах есть? То есть прод апгрейднули и виндовые контейнеры из-за несовместимости отвалились.

Как синхронизируете версии у разработчиков и на продакшене? Сложности при апгрейдах есть? То есть прод апгрейднули и виндовые контейнеры из-за несовместимости отвалились.

А причем тут k8s ?

при том, что k8s кластер может быть на виндовой машине. Значит версия виндовых контейнеров должна быть совместимой с версией контейнеров у девелоперов.

при том, что k8s кластер может быть на виндовой машине. Значит версия виндовых контейнеров должна быть совместимой с версией контейнеров у девелоперов.

Мне кажется нужно сюда https://t.me/devops_ru

@f545_j_43g43u_jer3tfgu32fh3333 о, спасибо за линк!

а там мне не скажут, что мне сюда? ?

а там мне не скажут, что мне сюда? ?

Тут больше вопрос про CI | CD. K8s тут не причем.

а там мне не скажут, что мне сюда? ?

Или интересует вопрос деплоя всего этого дела в k8s?

@f545_j_43g43u_jer3tfgu32fh3333 нет, именно вопрос синхронизации версий для совместимости контейнеров. Так что уже там написал ?

@f545_j_43g43u_jer3tfgu32fh3333 нет, именно вопрос синхронизации версий для совместимости контейнеров. Так что уже там написал ?

Это тогда точно в группу выше. Про k8s даже не обязательно упоминать)

k8s надо только в резюме упоминать, в приличном обществе могут мягко говорят не понять.

Кто-то работает с windows контейнерами?

у вас windows контейнере в куберенетесе? И как ощущения?

@vrutkovs пока нет еще, но вот-вот будут и я уже сам словил несовместимость версий между дев машинами. Отсюда и вопрос - как фиксить?

Всем привет, подскажите пытаюсь поставить kubernetes-dashboard kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml после этого kubectl get pods --all-namespaces -o wide | grep kubernetes-dashboard kube-system kubernetes-dashboard-767dc7d4d-vq77t 0/1 ContainerCreating 0 6m <none> node3 <none> а в логах это kubectl logs --namespace=kube-system pods/kubernetes-dashboard-767dc7d4d-vq77t error: You must be logged in to the server (the server has asked for the client to provide credentials ( pods/log kubernetes-dashboard-767dc7d4d-vq77t)) что-то не так с кластером?

О, опять дашборд

топчик

подскажите как принудительно прибить неймспейс? выдает ошибку kubectl delete ns ingress-nginx Error from server (Conflict): Operation cannot be fulfilled on namespaces "ingress-nginx": The system is ensuring all content is removed from this namespace. Upon completion, this namespace will automatically be purged by the system.

О, опять дашборд

не опять а снова

подскажите как принудительно прибить неймспейс? выдает ошибку kubectl delete ns ingress-nginx Error from server (Conflict): Operation cannot be fulfilled on namespaces "ingress-nginx": The system is ensuring all content is removed from this namespace. Upon completion, this namespace will automatically be purged by the system.

а кстати попробуй написать kubectl delete namespace ingress-nginx либо версия у тебя походу не та

сегодня на дурацкую проблему натолкнулся на v1.11 kubelet_node_status.go:391] Error updating node status, will retry: failed to patch status ... context deadline exceeded (Client.Timeout exceeded while awaiting headers) kubelet_node_status.go:391] Error updating node status, will retry: error getting node "k8s-2": Get https://127.0.0.1:6443/api/v1/nodes/k8s-2?timeout=4s: context deadline exceeded случилось на всех машинах в момент высокой нагрузки, но на одной из машин kubelet так и не смог добраться до апи kubelet_node_status.go:391] Error updating node status, will retry: error getting node kubelet_node_status.go:379] Unable to update node status: update node status exceeds retry count в итоге node not ready и убийство подов на машине. бугуртнул с этого

подскажите как принудительно прибить неймспейс? выдает ошибку kubectl delete ns ingress-nginx Error from server (Conflict): Operation cannot be fulfilled on namespaces "ingress-nginx": The system is ensuring all content is removed from this namespace. Upon completion, this namespace will automatically be purged by the system.

либо похоже он уже в статусе terminating , глянь ка

а кстати попробуй написать kubectl delete namespace ingress-nginx либо версия у тебя походу не та

пробовал. про версию чего ты имеешь ввиду? версия ингресса?

пробовал. про версию чего ты имеешь ввиду? версия ингресса?

покажи k get ns

ingress-nginx Terminating 60d

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

уже прошло 4 часа(

в неймспейсе ничего нет

так же создал тестовый нс и теперь его удалить не могу

уже прошло 4 часа(

k delete ns ingress-nginx —now=true —force=true —ignore-not-found=true

привет друзья! всех с наступающими выходными! пользуется кто нибудь eks? есть небольшой вопросец

привет друзья! всех с наступающими выходными! пользуется кто нибудь eks? есть небольшой вопросец

ага, в качестве репы для докера :D