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

Крон гадит?)

не

уже нашёл

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 юзать это плохая практика. Он был создан для доступа к системным каталогам и файлам хостов

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

Разберусь - перетащу в хранилище.

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

LAST SEEN FIRST SEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE 48m 58m 43 cloud-pvc.154ff7d6430b50f6 PersistentVolumeClaim Normal WaitForFirstConsumer persistentvolume-controller waiting for first consumer to be created before binding 3m 43m 163 cloud-pvc.154ff8ab7e09722b PersistentVolumeClaim Normal WaitForFirstConsumer persistentvolume-controller waiting for first consumer to be created before binding 1m 1h 277 fileshare-84cd866ffb-7m7kj.154ff5ff53c99a18 Pod Warning FailedScheduling default-scheduler persistentvolumeclaim "fileshare" not found 1m 1h 277 fileshare-84cd866ffb-gpqzg.154ff5ff2fb9a3b5 Pod Warning FailedScheduling default-scheduler persistentvolumeclaim "fileshare" not found 2m 2d 23278 kube-master.154f2544f6068b86 Node Normal CIDRNotAvailable cidrAllocator Node kube-master status is now: CIDRNotAvailable 2m 2d 23272 kube-node2.154f2544f623699f Node Normal CIDRNotAvailable cidrAllocator Node kube-node2 status is now: CIDRNotAvailable 2m 2d 23276 kube-node3.154f2544f6254887 Node Normal CIDRNotAvailable cidrAllocator Node kube-node3 status is now: CIDRNotAvailable

Ничего не видите?

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

Я бы вам посоветовал с nfs потренироваться лучше

я только начинаю осваивать куб

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

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

это вообще не относится к local-volume-provisioner (там свой provisioner) Просто визуально выглядит, что используете. Иначе зачем использовать StorageClass?

Я бы вам посоветовал с nfs потренироваться лучше

Потренироваться - это в каком смысле? Оно работает, но для полноценного требуется нормальное хранилище с репликацией, а не тупо виртуалка с диском...

Я бы вам посоветовал с nfs потренироваться лучше

когда немного освоюсь.. попробую его с glaster fs подружить

Понаступавши на глустерь, больше туда не пойду...

Потренироваться - это в каком смысле? Оно работает, но для полноценного требуется нормальное хранилище с репликацией, а не тупо виртуалка с диском...

Ну вы же осваиваете куб, с nfs можно было

это вообще не относится к local-volume-provisioner (там свой provisioner) Просто визуально выглядит, что используете. Иначе зачем использовать StorageClass?

я опирался на оф документацию... возможно глянул не туда((

там они сначала создают сторадж класс потом персистент волюм и клейм

Синтаксис конфигов и выделения ресурсов особо осваивать нечего... Тут больше дел погромистам пнуть на предмет "конфиги - отдельно, приложения отдельно", чтобы конфиги можно было через configMap подменить...

я опирался на оф документацию... возможно глянул не туда((

зашёл в документацию освежить память. https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes Выбрали local вместо hostPath?

когда немного освоюсь.. попробую его с glaster fs подружить

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

спокойно может ноды в 100% CPU подвесить

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

а что тогда лучше? цепх?

пока цеф выглядит рабочим, посмотрим как себя с кубером покажет

зашёл в документацию освежить память. https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes Выбрали local вместо hostPath?

local

пока цеф выглядит рабочим, посмотрим как себя с кубером покажет

ceph - отдельно от кубера или в виде rook?

local

local — local-volume-provisioner (https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume) Возможный ответ почему не смогло выбрать вольюм — второй пункт из пикчи, которую скидывал ранее

https://habr.com/company/southbridge/blog/419569/ Возможно новичкам как я будет полезно, очень доходчиво объясняют

Отдельно

local — local-volume-provisioner (https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume) Возможный ответ почему не смогло выбрать вольюм — второй пункт из пикчи, которую скидывал ранее

спасибо, сейчас буду глядеть))

Эмм. господа - может вопрос тупой, но.. У меня вдруг в кубере неймспейс ingress-nginx - стал вести себя как default, а default виден соответсвенно с явным указанием. что могло произойти.

Эмм. господа - может вопрос тупой, но.. У меня вдруг в кубере неймспейс ingress-nginx - стал вести себя как default, а default виден соответсвенно с явным указанием. что могло произойти.

~/.kube/config В контексте скорее всего указан namespace, который будет умолчанием https://kubernetes.io/docs/tasks/administer-cluster/namespaces-walkthrough/

Спасибо

Уже поправил - теперь надо понять как это могло произойти( или кому руки засунуть в нужное место). Еще раз Спасибо.

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

Репродюсер на гошечке? Может GC как то влияет

Надо б с GOMAXPROCS=1 , а вообще лучше б на С

Q: How will you ensure an uptime of 99.95%? A: With the help of DevOps-tools Ansible, Docker, Kubernetes and aligning CI/CD-processes.

Mkay.jpeg

Надо б с GOMAXPROCS=1 , а вообще лучше б на С

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

Всем привет. Кто подскажет, откуда в кубере берётся таймаут при коннекте к сервису? Версия 1.9.5, baremetal, kubespray, flannel. При запросе к сервису у которого нет эндпоинтов стабильно таймаут приходит через 130 секунд.

коллеги, гуглить не стал, на вскиду, к nginx я прикручивал basic авторизацию с ldap backend'ом

через ingress нужны танцы с бубнами, или через helm чарт все можно прокинуть?