Я думаю просто registry пытается сама затащить слой в память. Это ж не nginx

Не

Дисковый кэш не причем. У меня nginx с 100мб памяти нормально живут.

Приду домой - протестирую

И исходники регистри гляну. Но на 99% уверен - это файловый кэш

Ок, буду рад узнать, не думаю что у самого руки дойдут.

Если я правильно понимаю, то не надо давать юзерам ServiceAccount

Точно, спасибо

эм, если процессу дают ограничение по памяти, то сюда входит файл кэш? O_O

если на уровне cgroups - точно да

если на уровне cgroups - точно да

и там столько костылей зарыто, лучше этого не знать

+

Супер, нужно пересечься 👍

Супер, нужно пересечься 👍

Пиши, если что)

Всем привет подскажите пожалуйста зачем городить одельный кластер ectd для kubernets если 3 мастра и так хранят все в etcd ?

Так не городите. :)

так а зачем тогда такое предлогают наприер kubespray мне интересен мотив подобного решения

вчем соль ?

так а зачем тогда такое предлогают наприер kubespray мне интересен мотив подобного решения

По-моему дуют на воду. Если в вас будет такой огромный кластер, что упретесь в etcd, или у вас такие нагрузки, что etcd сразу будет тормозить, то вы и так и так его вынесете.

Ух, так зачем же на ноде кубера ещё непонятно что через докер композ стартовать? Если так делаете то пропишите в докер композ файле явно создание новой overlay network и чтобы все контейнеры в этом файле её юзали

Подозреваю что не поможет. По умолчанию создаётся, не overlay конечно, но вполне себе bridge, который в том числе можно настроить на доступ к внешке. Но дело в том что всё это работает через изменения iptables самим докером. Здесь главное не забыть проверить что докер можно обрезать опциями запуска, в том числе выключить изоляцию сети. Насчёт исключительности ноды кубера довольно спорное утверждение. Она такой же компьютер. Конкретно был случай необходимости запустить CI+тесты, так как другой машины под рукой не оказалось.

А что мешает запускать ci в кубере?

эм, если процессу дают ограничение по памяти, то сюда входит файл кэш? O_O

Да

А может кто подсказать - у local persistent volume обязательно размер указывать или можно так же как в докере - создай мне volume, а о свободном месте я позабочусь сам ?

1. Да обязательно, на основе этого параметра и нескольких других куб находит наиболее подходящий PV для каждого PVC 2. ЕМНИП Local-Volume provisioner не умеет создавать волумы по запросу. Чтобы PV появился в кубе, нужно натравить провижионер на директорию, затем вручную создать в ней mountpoint, только после этого провижионер добавит его как PV в кластер

Подозреваю что не поможет. По умолчанию создаётся, не overlay конечно, но вполне себе bridge, который в том числе можно настроить на доступ к внешке. Но дело в том что всё это работает через изменения iptables самим докером. Здесь главное не забыть проверить что докер можно обрезать опциями запуска, в том числе выключить изоляцию сети. Насчёт исключительности ноды кубера довольно спорное утверждение. Она такой же компьютер. Конкретно был случай необходимости запустить CI+тесты, так как другой машины под рукой не оказалось.

А ещё лучше запускайте это в dind

как раз таки dind снёс базу :)

dind для другого создавался, его создатель отговаривает использовать это для тестов

достаточно примонтировать сокет

Хм, ну я только для сборки его использую, запускаю sidecar'ом работает норм

как раз таки dind снёс базу :)

Это интересный случай, а расскажите поподробнее. Docker вроде бы все links в /etc/hosts прописывает

Какая у вас сеть была?

докер был запущен без собственного руля над iptables, поэтому никак не изолировал сеть. docker-compose не всегда справляется с резольвом ns-имён и разрешил postgres внутрь кластера, а не на тот что в compose

благо это стейджинг был, не жалко, но опыт не самый приятный

докер был запущен без собственного руля над iptables, поэтому никак не изолировал сеть. docker-compose не всегда справляется с резольвом ns-имён и разрешил postgres внутрь кластера, а не на тот что в compose

То есть docker-compose свой dns понимает?

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

Просто на сколько я помню, он использует встроенный в docker механизм links, а он все хостнэймы статически в /etc/hosts прописывает. Скорее всего забыли прописать нужную связь в docker-compose.yaml файлике. Из-за чего оно разрешило имя через хостовый resolve.conf

по идее достаточно только service прописать. compose файл 100% рабочий

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

недостаток времени и рук :)

Заодно манифест два раза переписывать не нужно будет: для docker-compose и для Kubernetes

Так а что за сеть для куба была?

калико

кубспрей позволяет включить изоляцию для докеров, но потестировать руки не дошли, возможно даже работает docker_iptables_enabled: "true"

На кубе нодах проще не запускать ничего не-куберного, чем придумывать обходные пути

Ребят а может ли nginx ingress проксировать на сервис в другом namespace (clusterip)

Всем привет! Немного повторюсь с вопросом. Что не так с RBAC у меня? --- apiVersion: v1 kind: ServiceAccount metadata: name: deployment-manager-serviceaccount namespace: develop --- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: Role metadata: namespace: develop name: deployment-manager-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["*"] - apiGroups: ["apps", "extensions"] resources: ["deployments", "statefulsets", ingresses", "replicasets"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: deployment-manager-rolebinding namespace: develop roleRef: kind: Role name: deployment-manager-role apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: deployment-manager-serviceaccount namespace: develop

Могу управлять и просматривать "apps", "extensions

Но вот pods, configmaps не работают

Уже делал resources: [""] и ничего не заработало

Ведь в первом rules я указал все apiGroups, в том числе и core, но почему то не работает

Подскажите пожалуйста по этому вопросу: https://toster.ru/q/569075

Подскажите пожалуйста по этому вопросу: https://toster.ru/q/569075

Версия куба какая?

Версия куба какая?

1.12

По kubespray ничего не скажу local_volume_provisioner_enabled: true local_volume_provisioner_base_dir: /mnt/disks local_volume_provisioner_mount_dir: /mnt/disks local_volume_provisioner_storage_class: local-storage конкретно про это, но local-storage работает из коробки в 11+

apiVersion: v1 kind: PersistentVolume metadata: name: mon3 spec: capacity: storage: 2Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete storageClassName: local-storage local: path: /var/vol1 nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - my-host-name

pv нужно делать руками

далее PersistentVolumeClaim уже сам выбирает куда пришвартоваться.

Ребят а может ли nginx ingress проксировать на сервис в другом namespace (clusterip)

Если нет никаких сетевых политик, например сеть flannel то без проблем

pv нужно делать руками

или провизионер искать

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

или провизионер искать

это baremetal обычно. Ни провизионеры, ни autoscale тут не работают... Ресурсы статичны.

Если нет никаких сетевых политик, например сеть flannel то без проблем

не до конца по правде понял , как мне указать его в ingress ns/default не хочется еще один подымать

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

Может. Нужна кластерроль с соответствующими правами.

далее PersistentVolumeClaim уже сам выбирает куда пришвартоваться.

вот эти пути должны быть разные? local: path: /var/vol1 и local_volume_provisioner_base_dir: /mnt/disks local_volume_provisioner_mount_dir: /mnt/disks

вот эти пути должны быть разные? local: path: /var/vol1 и local_volume_provisioner_base_dir: /mnt/disks local_volume_provisioner_mount_dir: /mnt/disks

local: path: /var/vol1 это путь на fs, где будут лежат pv данные. Насчет kubespray я не знаю за что отвечают эти флаги

У вас есть место, вы делаете пару pv, к примеру /var/vol1 /var/vol2 /var/vol3 через pvc поды их столбят на себя

kubespray тут не нужен в теории. Возможно это устаревшие флаги от 1.8 или 1.9 какого-то. в 11+ это работает из коробки.

не до конца по правде понял , как мне указать его в ingress ns/default не хочется еще один подымать

За приду гляну

local provisioner как раз таки будет делать pv, нужно только каталоги ручками создавать

всем привет

имеет ли смысл предпочесть стандартному centos centos atomic/fedora atomic/core os ?

имеет ли смысл предпочесть стандартному centos centos atomic/fedora atomic/core os ?

а зачем?

а зачем?

вот я и задаюсь вопросом - "зачем"

вот я и задаюсь вопросом - "зачем"

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

пока нет, до тех пор пока не выйдет Fedora CoreOS

но в целом приемущество конечно есть - атомарные транзакции, смена веток и так далее

понял, спасибо

примерно такого же мнения, но решил попробовать развернуть из fedora-atomic

документация "шикарная"

но в целом приемущество конечно есть - атомарные транзакции, смена веток и так далее

и зачем всё это надо если у тебя просто кубер?

и зачем всё это надо если у тебя просто кубер?

+ рантайм, selinux, iptables / firewalld, ceph-common и т.д.

Добрый день. Подскажите установил kubernetes через kubespray. Дашбор не открывается, ставил его по инструкции с оф. сайта. Kubernetes master is running at http://localhost:8080 KubeDNS is running at http://localhost:8080/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy kubernetes-dashboard is running at http://localhost:8080/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy В чем причина?

+ рантайм, selinux, iptables / firewalld, ceph-common и т.д.

Вообще, идиально было бы, чтобы ноды можно было бутстрапить через cloud init

Вообще, идиально было бы, чтобы ноды можно было бутстрапить через cloud init

можно, только очень больно. Для этого есть ignition