Какая-то проблема именно в 18.04? Issue где-нибудь есть? На 16.04 c докером 17.03 все точно работает

На старых не проверяли, issue (точнее вопрос) на ланчпаде есть

@SinTeZoiD

@SinTeZoiD

тыж говорил бот работает

тыж говорил бот работает

он новоприбывших мьютит

а

этот зашел с утра

Включи логдрайвер журналды и попробуй почитать логи через docker logs

Оно нигде не работает :) убунта не при чем, просто kubectl logs умеет читать только из файла, а файл пишет только JSON логдрайвер

вот и нет

с не-убунтовым докером работает

с обычным из докер-репозитория

И он при этом продолжает писать в journald?

угу

и писать и читать

+1 редхатовский докер тоже умеет без jsonfile

Вот оно как оказывается! https://github.com/kubernetes/kubernetes/pull/42195/files

Вобщем все что хранит логи локально - работает. Буду знать

https://answers.launchpad.net/ubuntu/+source/docker.io/+question/671491

zbs

@SinTeZoiD ты не поверишь, но этот тоже пришел до Большого Брата :)

/report

неработает репорт

@SinTeZoiD ты не поверишь, но этот тоже пришел до Большого Брата :)

Да верю

Почему же)

как чистить историю запускаемых джобов?

как чистить историю запускаемых джобов?

А порно режима как в браузере нет? Что бы хистори не сохранилось?)

А порно режима как в браузере нет? Что бы хистори не сохранилось?)

/report

ну а серьёзно?

есть фича почистить историю джобов?

/report

Да ты охренел! Крутая же фича была бы

готов реализовать?

есть фича почистить историю джобов?

Крон гадит?)

не

уже нашёл

successfulJobsHistoryLimit: X failedJobsHistoryLimit: Y

хм, кажется это только для кронджобов :/

для обычных джобов не катит

что-то не врубаюсь как будет работать джоба с manualSelector: true

https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#specifying-your-own-pod-selector четыре раза перечитал и всё равно не очень понимаю что это значит

точнее, не очень понимаю зачем это

Ни у кого нет случайно RBAC, который позволит создавать и модифицировать ресурсы в кубере, но не позволит их удалять? Я хочу деплоить через гитлаб-раннер, но не хочу давать ему cluster-admin

на неймспейс права edit можно выдать

Ни у кого нет случайно RBAC, который позволит создавать и модифицировать ресурсы в кубере, но не позволит их удалять? Я хочу деплоить через гитлаб-раннер, но не хочу давать ему cluster-admin

Delete у rbac-а отдельное свойство

на неймспейс права edit можно выдать

Но нагадить можно и так)

Ни у кого нет случайно RBAC, который позволит создавать и модифицировать ресурсы в кубере, но не позволит их удалять? Я хочу деплоить через гитлаб-раннер, но не хочу давать ему cluster-admin

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

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

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

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

Смотря что и кому. Минигуй (роллбек/апгрейд) для хельма наверное нужен :)

Желательно с лдапом и шл...и, но это отдельная история

неработает репорт

они начали о чем-то догадываться!

Всем! Не получается обновить ssl_protocols для nginx-ingress. Кто-нибудь сталкивался? kind: ConfigMap apiVersion: v1 metadata: name: nginx-config data: ssl-ciphers: "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA" ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2" После обновляю деплоймент: kubectl -n kube-system patch ds/ingress-nginx-ingress-controller -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}" (edited)

Приветствую! Помогите разобраться, почему websocket при проксировании на ингресс не работает Есть такая конфигурация Nginx (proxy) -> Ingress (nginx) -> backend Ингресс открыт наружу nodeport-ом Если подключиться напрямую - вебсокет работает wscat -n -c ws://domain.com:32080/ws connected (press CTRL+C to quit Но если подключаться к прокси, то получаю 404-ую ошибку от default backend-а На прокси локейшен настроен следующим образом location /ws { proxy_pass http://k8s_http; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_send_timeout 3600s; proxy_read_timeout 3600s; } Апгрейд коннекшена установлен соответсвующими заголовками, в чем может быть проблема?

А в самом ингрессе аннотиации правил?

Вот так например apiVersion: extensions/v1beta1 kind: Ingress metadata: name: my-ingress annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/affinity: cookie nginx.ingress.kubernetes.io/proxy-read-timeout: "3600" nginx.ingress.kubernetes.io/proxy-send-timeout: "3600" nginx.ingress.kubernetes.io/session-cookie-hash: sha1 nginx.ingress.kubernetes.io/session-cookie-name: route spec: ...

Ты у меня спрашиваешь? Так тоже пробовал

Ты у меня спрашиваешь? Так тоже пробовал

Проверь версию ингреса, вроде поддержка ws-а не сразу была

никого не смущает 404 от default-backend?

Нет.

https://github.com/kubernetes-incubator/external-storage/pull/962

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

Господа, а кто натыкался на неоправданно высокий троттлинг по цпу? Начал копать, нашел вот этот баг https://bugzilla.kernel.org/show_bug.cgi?id=198197 У кого воспроизводится/кто как борется?

Привет! подскажите по PersistentVolume. Создал StorageClass, PersistentVolume и PersistentVolumeClaim. PersistentVolume не биндиться, PersistentVolumeClaim постоянно в пендинге, persistentvolume-controller waiting for first consumer to be created before binding --- kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: local-storage provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer --- kind: PersistentVolume apiVersion: v1 metadata: name: pv-cloud spec: storageClassName: local-storage capacity: storage: 5Gi accessModes: - ReadWriteOnce hostPath: path: "/mnt/disks/vol1" --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: cloud-pvc spec: storageClassName: local-storage accessModes: - ReadWriteOnce resources: requests: storage: 2Gi гдето допустил ошибку но пока не могу понять где

describe pvc

Name: cloud-pvc Namespace: default StorageClass: local-storage Status: Pending Volume: Labels: <none> Annotations: <none> Finalizers: [kubernetes.io/pvc-protection] Capacity: Access Modes: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal WaitForFirstConsumer 4m (x123 over 34m) persistentvolume-controller waiting for first consumer to be created before binding

или describe StorageClass

Name: local-storage IsDefaultClass: No Annotations: <none> Provisioner: kubernetes.io/no-provisioner Parameters: <none> AllowVolumeExpansion: <unset> MountOptions: <none> ReclaimPolicy: Delete VolumeBindingMode: WaitForFirstConsumer Events: <none>

/mnt/disks/vol1 хоть где-то существует, кстати? :-)

/mnt/disks/vol1 хоть где-то существует, кстати? :-)

на всех нодах вручную создал

на всех нодах вручную создал

просто папка или маунт?

папка

Хм.... У меня так: kind: PersistentVolume apiVersion: v1 metadata: name: mongo-pv labels: type: local spec: storageClassName: manual accessModes: - ReadWriteMany hostPath: path: "/data/mongo" capacity: storage: 3Gi --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: mongo-pv-claim spec: storageClassName: manual accessModes: - ReadWriteMany resources: requests: storage: 1Gi

вроде работает...

а описание стораджкласса можно глянуть?

Но у меня 1) единственное хранилище на выделенном воркере, 2) деплой привязан к узлу.

стораджкласс не создавал, это из стандартных

а описание стораджкласса можно глянуть?

он не использует local-volume-provisioner

kubectl -n <namespace> get events дайте

Хм.... У меня так: kind: PersistentVolume apiVersion: v1 metadata: name: mongo-pv labels: type: local spec: storageClassName: manual accessModes: - ReadWriteMany hostPath: path: "/data/mongo" capacity: storage: 3Gi --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: mongo-pv-claim spec: storageClassName: manual accessModes: - ReadWriteMany resources: requests: storage: 1Gi

попробовал так..сработало

он не использует local-volume-provisioner

и я тоже не использую Provisioner: kubernetes.io/no-provisioner

Хм.... У меня так: kind: PersistentVolume apiVersion: v1 metadata: name: mongo-pv labels: type: local spec: storageClassName: manual accessModes: - ReadWriteMany hostPath: path: "/data/mongo" capacity: storage: 3Gi --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: mongo-pv-claim spec: storageClassName: manual accessModes: - ReadWriteMany resources: requests: storage: 1Gi

hostPath юзать это плохая практика. Он был создан для доступа к системным каталогам и файлам хостов

Пока не разобрался с нормальным хранилищем - навалили после отпуска всякого...