❤️

Добрый день! Прошу помощи, команда kubectl delete pod pod-name залипает навсегда. Спасает kubectl delete pod pod-name --force --grace-period=0 все бы ничего но из-за этого деплой helm'ом отваливается с ошибкой по таймайту... Дайте хоть намек где искать? kubectl delete pod pod-name -v 9 ничего не пишет, 200 OK и тишина потом...

Добрый день! Прошу помощи, команда kubectl delete pod pod-name залипает навсегда. Спасает kubectl delete pod pod-name --force --grace-period=0 все бы ничего но из-за этого деплой helm'ом отваливается с ошибкой по таймайту... Дайте хоть намек где искать? kubectl delete pod pod-name -v 9 ничего не пишет, 200 OK и тишина потом...

kubectl describe pod

Угу пробовал. Пишет нет такого пода. Хотя он есть и висит в списке со статусом Terminated

Угу пробовал. Пишет нет такого пода. Хотя он есть и висит в списке со статусом Terminated

дефолтный grace period какой? а хуки у пода есть? может хук повисает, а grace выставлен большой

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

Друзья, есть у кого рабочий ямл ингресса под https dashboard? у меня скоро кровь и з глаз пойдет

присоединюсь к испытывающим трудности удаления - почему персистент-вольюмы не пишутся по get all и при попытке удалить ответа нет, а вольюм висит в статусе терминэйтИНГ, сорри?

Добрый день! Прошу помощи, команда kubectl delete pod pod-name залипает навсегда. Спасает kubectl delete pod pod-name --force --grace-period=0 все бы ничего но из-за этого деплой helm'ом отваливается с ошибкой по таймайту... Дайте хоть намек где искать? kubectl delete pod pod-name -v 9 ничего не пишет, 200 OK и тишина потом...

смотри в логи твоего контейнерного рантайма

дефолтный grace period какой? а хуки у пода есть? может хук повисает, а grace выставлен большой

а вот как это посмотреть? Я тоже думаю что дефолтный грайс слишком большой

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

это как можно сделать можно подробности?

смотри в логи твоего контейнерного рантайма

это где такие?

если я что то затупил, сори тяжелый день

а вот как это посмотреть? Я тоже думаю что дефолтный грайс слишком большой

можно грепнуть terminationGracePeriod в kubectl describe pod

возможно его еще можно ключем для kube-controller-manager можно менять, я хз. можно еще на ключи запуска в control plane глянуть

По аналогии https://github.com/kubernetes/kubernetes/issues/19317

env TZ=UTC date Ср июн 5 14:27:00 UTC 2019 env TZ=MSK date Ср июн 5 14:27:06 MSK 2019

Если я не ошибаюсь, то переменная TZ работает не со всем софтом. К тому же требует установленного tzdata. Буду рад ошибаться.

Если я не ошибаюсь, то переменная TZ работает не со всем софтом. К тому же требует установленного tzdata. Буду рад ошибаться.

Ну вроде сработало

И в деплойменте с волюмом

и при експорте

Друзья, есть у кого рабочий ямл ингресса под https dashboard? у меня скоро кровь и з глаз пойдет

у меня есть

пазяляста

присоединюсь к испытывающим трудности удаления - почему персистент-вольюмы не пишутся по get all и при попытке удалить ответа нет, а вольюм висит в статусе терминэйтИНГ, сорри?

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

всем здрасьте! подскажите пожалуйста. пытаюсь запустить в одном поде два контейнера, один бек и nginx для статики к нему. не понимаю как в конфиге nginx'a сделать upstream для бека. все запросы должны идти только через nginx. или так вообще не стоит делать?

ingress controller - это простая штука которая мне уже съела весь мозг почему то

пазяляста

ты на слерм-4 был ? я там приводил пример

был

ingress controller - это простая штука которая мне уже съела весь мозг почему то

https://medium.com/@doug.hellinger/how-to-expose-kubernetes-dashboard-through-nginx-ingress-controller-with-custom-ssl-certificate-c25167887963

Ну вот же

:C

в анотациях там ничего особенного нет кроме того что ssl-backends?

https://medium.com/@doug.hellinger/how-to-expose-kubernetes-dashboard-through-nginx-ingress-controller-with-custom-ssl-certificate-c25167887963

устарело. аннотации нерабочие

был

kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/proxy-send-timeout: "300" nginx.ingress.kubernetes.io/proxy-read-timeout: "300" nginx.ingress.kubernetes.io/whitelist-source-range: 1.1.1.1/32,2.2.2.2/32 nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" certmanager.k8s.io/cluster-issuer: letsencrypt labels: app: kube-api name: kube-api namespace: default spec: rules: - host: k8s-api.s000.slurm.io http: paths: - backend: serviceName: kubernetes servicePort: 443 path: / tls: - hosts: - k8s-api.s000.slurm.io secretName: k8s-api-s000-slurm-io-tls

устарело. аннотации нерабочие

Тогда грустно

Спасибо, буду посмотреть

без tls на ингрессе работать не будет.

всем здрасьте! подскажите пожалуйста. пытаюсь запустить в одном поде два контейнера, один бек и nginx для статики к нему. не понимаю как в конфиге nginx'a сделать upstream для бека. все запросы должны идти только через nginx. или так вообще не стоит делать?

подскажи плз

ай. ой. сорри

nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" = nginx.ingress.kubernetes.io/secure-backends: "true" ??

Спасибо, буду посмотреть

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

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

это понятно

nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" = nginx.ingress.kubernetes.io/secure-backends: "true" ??

ну почти. они поменяли аннотацию. и старый вариант игнорится

у меня почему то вот что происходит в логах nginx: 92.168.0.167 - [192.168.0.167] - - [05/Jun/2019:15:08:24 +0000] "GET / HTTP/2.0" 009 7 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0" 14 0.001 [kube-system-kubernetes-dashboard-443] 10.233.109.2:8443 7 0.001 200 e4609e2930fdeab5ffe8c790af6f37d3 2019/06/05 15:08:27 [error] 195#195: *27060 upstream sent no valid HTTP/1.0 header while reading response header from upstream, client: 192.168.0.167, server: dashboard.test.sphaera.local, request: "GET / HTTP/2.0", upstream: "http://10.233.109.2:8443/", host: "dashboard.test.sphaera.local" 2019/06/05 15:08:27 [error] 195#195: *27060 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.0.167, server: dashboard.test.sphaera.local, request: "GET / HTTP/2.0", upstream: "http://10.233.109.2:8443/", host: "dashboard.test.sphaera.local"

upstream: "http://10.233.109.2:8443/

http

п нпдо https

nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

это?

yes

nginx.ingress.kubernetes.io/secure-backends: "true" так работать не будет?*

а у тебя ingress контроллер nginx ?

или какой ?

да

у меня почему то вот что происходит в логах nginx: 92.168.0.167 - [192.168.0.167] - - [05/Jun/2019:15:08:24 +0000] "GET / HTTP/2.0" 009 7 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0" 14 0.001 [kube-system-kubernetes-dashboard-443] 10.233.109.2:8443 7 0.001 200 e4609e2930fdeab5ffe8c790af6f37d3 2019/06/05 15:08:27 [error] 195#195: *27060 upstream sent no valid HTTP/1.0 header while reading response header from upstream, client: 192.168.0.167, server: dashboard.test.sphaera.local, request: "GET / HTTP/2.0", upstream: "http://10.233.109.2:8443/", host: "dashboard.test.sphaera.local" 2019/06/05 15:08:27 [error] 195#195: *27060 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.0.167, server: dashboard.test.sphaera.local, request: "GET / HTTP/2.0", upstream: "http://10.233.109.2:8443/", host: "dashboard.test.sphaera.local"

как ты nginx настраивал?

nginx.ingress.kubernetes.io/secure-backends: "true" так работать не будет?*

говорю же. устарело и потрачено

я поставил его helm'om, убил сервис, допилил деплоймент на hostNetwork

ок, ок.. наверное в этом была проблема

Блин, из за ссылки удалилось сообщение?

Блин, из за ссылки удалилось сообщение?

теперь пиши с ссылкой

❤️

Всем привет! Не могу понять прикол с выдачой сертификата Пытаюсь выдать сертификат на 20 доменов в одном кластере Проблема в том, что на некоторые домены выдается сертифкат за 2 минуты, а некоторые домены висят уже по пол часа и ничего не показывает кроме как Created new ACME order, attempting validation... У каждого домена свой namespace Сам issuer apiVersion: certmanager.k8s.io/v1alpha1 kind: Issuer metadata: name: letsencrypt namespace: <NAMESPACE> spec: acme: server: https://acme-v02.api.letsencrypt.org/directory email: admin@<DOMAIN> privateKeySecretRef: name: letsencrypt http01: {} Certificate: apiVersion: certmanager.k8s.io/v1alpha1 kind: Certificate metadata: name: <NAMESPACE> namespace: <NAMESPACE> spec: secretName: <NAMESPACE> issuerRef: name: letsencrypt dnsNames: - <DOMAIN> - www.<DOMAIN> acme: config: - http01: ingressClass: nginx domains: - <DOMAIN> - www.<DOMAIN> расскажите в чём может быть проблема?

возращаясь к моим баранам I0605 15:49:49.613823 1 log.go:172] http: TLS handshake error from 172.16.0.8:48726: remote error: tls: bad certificate мне кажется это как то связано)

хотя все ноды ready

172.16.0.8 это node-2 если что) и таких сообщейний в api-kubernetes ооочень много

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

надо логи cert-manager смотреть

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

например лимит регистрации новых аккаунтов с одного ip адреса

это серты кубера

у меня нет серт менеджера

игнор 🙁

всем здрасьте! подскажите пожалуйста. пытаюсь запустить в одном поде два контейнера, один бек и nginx для статики к нему. не понимаю как в конфиге nginx'a сделать upstream для бека. все запросы должны идти только через nginx. или так вообще не стоит делать?

localhost и порт открытывый на беке

например лимит регистрации новых аккаунтов с одного ip адреса

Спасибо за ответ! А какой там лимит? И как мне тогда сделать? Регистрировать просто один ClusterIssuer и потом через него все делать или?

Спасибо за ответ! А какой там лимит? И как мне тогда сделать? Регистрировать просто один ClusterIssuer и потом через него все делать или?

https://letsencrypt.org/docs/rate-limits/

localhost и порт открытывый на беке

спасибо 👍

You can create a maximum of 10 Accounts per IP Address per 3 hours. You can create a maximum of 500 Accounts per IP

The main limit is Certificates per Registered Domain (50 per week).