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

+

вообще к8 - не продукт и никогда им не был

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

а где-то она не сырая?

а где-то она не сырая?

в том и вопрос

все пилят свои велосипеды

по-разному херовые :)

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

https://kubeapps.com/ все вкусное тут

а где-то она не сырая?

ну в гитлабе она прям вообще стремится к нулю( красиво маркетологи разрекламировали, на деле не так красиво)

найти бы кого-нибудь, чтобы подсказал куда копать, а то у нас вроде order на сертификат есть, но он висит

так а логи смотреть?

так а логи смотреть?

Смотрели, оно зависает и думает все ещё

чем выписываете хоть?

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

Господа трабла. Мастер на AWS с эластик IP как положено. Миньйон в хезнере. Когда создаю кластер всё ок. Без ошибок. Но что-то с прокси. Я создаю дашборд и пытаюсь подключиться через ssh туннель с kube proxy выдаёт тайм-аут пытаюсь через апи, тоже борода.

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

В том и дело, даже непонятно где "бобо", запрос за сертификат ушел, order есть, а что дальше - непонятно

бросайте вы это, батенька.

не ваше это

Может кто сталкивался с проблемой что поды не запускаются с такой ошибкой: OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:402: container init caused \"rootfs_linux.go:58: mounting \\\"/var/lib/kubelet/pods/04177b8f-94c4-11e8-bee2-080027707b4a/volumes/kubernetes.io~secret/default-token-qhc6m\\\" to rootfs \\\"/var/lib/docker/overlay2/949a039a23bee2b5d89b8849214e2b409cbba54dc0dc1012409281de8b063e82/merged\\\" at \\\"/var/lib/docker/overlay2/949a039a23bee2b5d89b8849214e2b409cbba54dc0dc1012409281de8b063e82/merged/run/secrets/kubernetes.io/serviceaccount\\\" caused \\\"mkdir /var/lib/docker/overlay2/949a039a23bee2b5d89b8849214e2b409cbba54dc0dc1012409281de8b063e82/merged/run/secrets/kubernetes.io: read-only file system\\\"\"": unknown

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

В том и дело, даже непонятно где "бобо", запрос за сертификат ушел, order есть, а что дальше - непонятно

какой инструмент используете для выписывания сертификатов?

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

какие записи там были?

cert-manager? kube-lego? выписываете через dns? http?

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

cert-manager, сейчас детально коллега подскажет :)

http

наконец-то :)

логи пода, в котором cert-manager крутится, смотрели? что там?

может у вас авторизация не проходит

выписываете сразу на prod, или пробуете на staging?

пробовали и так, и сяк, везде одинаково

логи смотрели, в основном ошибка в том, что нет secret нужного

создаем - ругается что пусто

Может кто сталкивался с проблемой что поды не запускаются с такой ошибкой: OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:402: container init caused \"rootfs_linux.go:58: mounting \\\"/var/lib/kubelet/pods/04177b8f-94c4-11e8-bee2-080027707b4a/volumes/kubernetes.io~secret/default-token-qhc6m\\\" to rootfs \\\"/var/lib/docker/overlay2/949a039a23bee2b5d89b8849214e2b409cbba54dc0dc1012409281de8b063e82/merged\\\" at \\\"/var/lib/docker/overlay2/949a039a23bee2b5d89b8849214e2b409cbba54dc0dc1012409281de8b063e82/merged/run/secrets/kubernetes.io/serviceaccount\\\" caused \\\"mkdir /var/lib/docker/overlay2/949a039a23bee2b5d89b8849214e2b409cbba54dc0dc1012409281de8b063e82/merged/run/secrets/kubernetes.io: read-only file system\\\"\"": unknown

read-only filesystem? попробуйте в /var/ что-нибудь записать

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

создаем - ругается что пусто

clusterissuer используете?

Да

read-only filesystem? попробуйте в /var/ что-нибудь записать

это же насколько я понимаю идет монтирование папок для секретов

а на какой секрет жалуется? сертификата? или аккаунта?

а на какой секрет жалуется? сертификата? или аккаунта?

сертификата

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

как на staging получите fake сертификат - переключайте на прод

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

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

окей, значит может пройти само, без нас :D

ошибка с секретом может быть наведённой, смотрите выше по логам ещё

ну и скажите точный текст ошибки, я у себя посмотрю

certificates controller: Re-queuing item "coffee/coffee-tls" due to error processing: http-01 self check failed for domain ""

это же насколько я понимаю идет монтирование папок для секретов

тем не менее проверить стоит

read-only filesystem? попробуйте в /var/ что-нибудь записать

если что это я под миникубом запускаю все, зашел в него через minikube ssh пользователь docker - просто в папке var ему запсь не дана

ну и домен конечно указан

certificates controller: Re-queuing item "coffee/coffee-tls" due to error processing: http-01 self check failed for domain ""

так это

Error preparing issuer for certificate coffee/coffee-tls: http-01 self check failed for domain ""

проверка упала

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

nginx

секунду

ссылка формата .well-known доступна

падает после Calling GetChallenge

а домен точно резолвится везде в ваш ip?

да

ну и попробуйте в ресурсе сертификата вот так сделать apiVersion: certmanager.k8s.io/v1alpha1 kind: Certificate metadata: name: expi-web-certificate namespace: default spec: secretName: expi-web-certificate-tls issuerRef: name: {{ .Values.letsencrypt.issuer }} kind: ClusterIssuer commonName: {{ .Values.ingress.name }} # w/a for rewrite-target from https://github.com/jetstack/cert-manager/issues/286#issuecomment-361033891 acme: config: - http01: { ingressClass: nginx } domains: [ {{ .Values.ingress.name }} ]

я про { ingressClass: nginx }

сейчас проверим

@gorilych No existing HTTP01 challenge solver pod found for Certificate "coffee/coffee-tls". One will be created.

это вначале

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

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

недолго, в пределах минут

вторая итерация - снова упал

меня смущает Looking up Ingresses for selector certmanager.k8s.io/acme-http-domain=892143170,certmanager.k8s.io/acme-http-token=1177816782

и почему-то в начале все равно Created order for domains: [{dns domain}]

Ктото юзает containerd в проде? Как оно?

тем не менее проверить стоит

кстати запустил с такими же параметрами но с базовым образом busybox - и там такой ошибки нет. А вот интересующий меня образ собран на alpine

и почему-то в начале все равно Created order for domains: [{dns domain}]

прям так и написано domain? или имя вашего домена?

имя домена, конечно

после created orders в логах cert-manager есть что-то ещё? Должно быть Calling HTTP01ChallengeResponse и Calling GetChallenge

вот после GetChallenge и падает, т.е. других Call нет

делает Looking up Ingresses for selector certmanager.k8s.io/acme-http-domain=892143170,certmanager.k8s.io/acme-http-token=1177816782 I0731 14:15:58.610921 1 helpers.go:188] Found status change for Certificate "coffee-tls" condition "Ready": "False" -> "False"; setting lastTransitionTime to 2018-07-31 14:15:58.610899663 +0000 UTC m=+6951.477279875 и все, потом пишет что failed

с { ingressClass: nginx } cert-manager должен динамически создавать ingress правила и поды под них. Можете попытаться поймать их с помощью kubectl get po,ingress --all-namespaces

ну и посмотреть yaml структуру

окей, поищу, спасибо ближе к вечеру отпишусь =)

Здарова, хочу очень странного, нужно делать docker commit и docker push для контейнеров в подах в кубере по запросу. Из вариантов вижу daemonset который имеет доступ к сокету рантайма контейнерного и отрабатывает запросы. Вопрос тут скорее в том какой можно ли передачу такого рода запросов сделать на возможностях кубера и как, может сталкивался кто с похожим?

?

Здарова, хочу очень странного, нужно делать docker commit и docker push для контейнеров в подах в кубере по запросу. Из вариантов вижу daemonset который имеет доступ к сокету рантайма контейнерного и отрабатывает запросы. Вопрос тут скорее в том какой можно ли передачу такого рода запросов сделать на возможностях кубера и как, может сталкивался кто с похожим?

d-in-d реализует нужное Вам, но без кубика.

d-in-d реализует нужное Вам, но без кубика.

мне на кубике надо, именно в кубере будут запущены эти контейнера и в определенные моменты их надо будет коммитить и пушить, криво, да, но надо :(

без registry по всем node?

хм, да, по всем нодам, где будут запущены соответствующие поды

регистри будет отдельно, ecr скорее всего для начала

Здарова, хочу очень странного, нужно делать docker commit и docker push для контейнеров в подах в кубере по запросу. Из вариантов вижу daemonset который имеет доступ к сокету рантайма контейнерного и отрабатывает запросы. Вопрос тут скорее в том какой можно ли передачу такого рода запросов сделать на возможностях кубера и как, может сталкивался кто с похожим?

Buildah в контейнере

Buildah в контейнере

Спасибо

Buildah в контейнере

А он сможет конейнера подов в кубере коммитить и пушить?

А он сможет конейнера подов в кубере коммитить и пушить?

Сам под? Нет, но внутри него сможет. Нужно SYS_CAP_ADMIN ну или privileged

Может crictl сможет

Может crictl сможет

Неа, надо дописывать

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