на cri-o уже мигрировал кто?

Ingress or NodePort\Loadbalancer or kubectl port-forward

Спасибо. А как правильнее в экосистеме куба это делать? Ingress ?

на cri-o уже мигрировал кто?

сравнение есть какое-то?

Спасибо. А как правильнее в экосистеме куба это делать? Ingress ?

как нужно так и делать) Ингресс из коробки имеет только 2 вида авторизации: basic (некоторые контроллеры могут digest) auth и client certificate

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

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

тут скорее не так)

нужен ли тебе докер или достаточно ли тебе cri-o

в cri-o все заточено под кубер, там нет лишних никаких штук

ок, уловил

в cri-o все заточено под кубер, там нет лишних никаких штук

А образы совместимы или это своя экосистема?

Есть почитать че интересное?

А образы совместимы или это своя экосистема?

containers/images для образов юзается

должны быть совместимы, API же одно

https://habrahabr.ru/company/flant/blog/340010/ вот в принципе

Спасибо

должны быть совместимы, API же одно

а вот из докер cli нельзя подключится к cri-o)

не, ну cli — это же имплементация

я про кишки (внутри там должно быть стандартизировано)

докер не очень придерживается стандартов)

тот же containerd не имплементит CRI

и делают свой cri-containerd поверх

печаль

а вот из докер cli нельзя подключится к cri-o)

для этого есть podman

вообще в cri-o OCI-совместимые образы, но можно импортировать из докера

а crictl не про это?

crictl - это для интерфейса (CRI), crio - одна из реализаций этого интерфейса

для этого есть podman

я больше к тому что cri-o не совсем совместим с докером

я больше к тому что cri-o не совсем совместим с докером

ну да, потому что docker cli делает слишком много с точки зрения crio

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

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

в этом и была суть cri-o)

минимально и все под нужды кубера

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

и все же изначальный вопрос актуален. кто-то уже перепрыгнул на cri-o в проде?

Ребят, вопрос наверное до жути глупый, но как я могу вытащить dashboard куба наружу? Чтоб не ходить на локалхост через ssh туннель

по умолчанию через api сервер https://<apiserver>/ui

и все же изначальный вопрос актуален. кто-то уже перепрыгнул на cri-o в проде?

некоторые ноды на free tier в openshift online работают на crio, но пока есть баги и не хватает тулзов для полной замены

некоторые ноды на free tier в openshift online работают на crio, но пока есть баги и не хватает тулзов для полной замены

а можно подробнее про то, чего не хватает?

а можно подробнее про то, чего не хватает?

например, fluentd не понимает логов cri-o

нужен ли тебе докер или достаточно ли тебе cri-o

Докер сукин сын, но он наш сукин сын

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

тот же containerd не имплементит CRI

Ниче что CRI появился позже containerd? :)

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

insecure в смысле?

insecure в смысле?

и secure тоже. Хотя в докере слово secure лучше писать в кавычках

"Как это - проверять имаджи после пулла? sha256 должно хватить всем!"

и все же изначальный вопрос актуален. кто-то уже перепрыгнул на cri-o в проде?

Перевелись ковбои! Покажите собой пример отваги

"Как это - проверять имаджи после пулла? sha256 должно хватить всем!"

А что, не хватает?

А что, не хватает?

https://github.com/moby/moby/issues/9719. tl;dr пока хватает, но почему бы не перейти на нормальный gpg (который позволил бы по-человечески делать мирроры) мне не ясно

https://github.com/moby/moby/issues/9719. tl;dr пока хватает, но почему бы не перейти на нормальный gpg (который позволил бы по-человечески делать мирроры) мне не ясно

Вы знаете об интересных нюансах. Кем работаете?

#whois Инженер в Red Hat, работаю над ansible репозиторием для установки openshift

Вы знаете об интересных нюансах. Кем работаете?

помоему это на лоре или на хабре где-то было недавно

Ребят, а почему после создания ingress, поды под него могут не подниматься?

Где бы хоть логов глянуть

Где бы хоть логов глянуть

kubectl logs -f --namespace kube-system nginx-ingress-controller

describe тоже работает

kubectl logs -f --namespace kube-system nginx-ingress-controller

Спасибо. Команда говорит что его нет: #kubectl logs -f --namespace kube-system nginx-ingress-controller Error from server (NotFound): pods "nginx-ingress-controller" not found

Но в дашборде я его вижу

по дашборде не гадаю kubectl get po --namespace kube-system

# kubectl get po --namespace kube-system NAME READY STATUS RESTARTS AGE calico-node-9fvcq 1/1 Running 0 3d calico-node-k2bp7 1/1 Running 0 3d calico-node-w8mlm 1/1 Running 0 3d default-http-backend-5f497b585f-wlm4t 1/1 Running 0 21m kube-apiserver-kube01 1/1 Running 0 3d kube-apiserver-kube02 1/1 Running 0 3d kube-controller-manager-kube01 1/1 Running 0 3d kube-controller-manager-kube02 1/1 Running 0 3d kube-dns-79d99cdcd5-5kxgx 3/3 Running 0 3d kube-dns-79d99cdcd5-gmkpt 3/3 Running 0 3d kube-proxy-kube01 1/1 Running 0 3d kube-proxy-kube02 1/1 Running 0 3d kube-proxy-kube03 1/1 Running 0 3d kube-scheduler-kube01 1/1 Running 0 3d kube-scheduler-kube02 1/1 Running 0 3d kubedns-autoscaler-5564b5585f-hk9l4 1/1 Running 0 3d kubernetes-dashboard-6bbb86ffc4-4h4w7 1/1 Running 0 3d nginx-proxy-kube03 1/1 Running 0 3d

ну может он в другом нэймспэйсе?

кажется разобрался. У меня там node-selector стоял.

а нод таких не было

убрал селектор, но теперь другая проблема: I0215 10:04:41.388959 7 launch.go:94] &amp;{NGINX 0.9.0-beta.2 git-7013a52 git@github.com:ixdy/kubernetes-ingress.git} I0215 10:04:41.388989 7 launch.go:97] Watching for ingress class: nginx I0215 10:04:41.387575 7 nginx.go:112] starting NGINX process... I0215 10:04:41.390230 7 launch.go:223] Creating API server client for https://10.233.0.1:443 F0215 10:04:41.418959 7 launch.go:111] no service with name kube-system/default-http-backend found: services "default-http-backend" is forbidden: User "system:serviceaccount:kube-system:default" cannot get services in the namespace "kube-system" Вроде понятно что прав не хватает. Но где взять правильного юзера и как его прописать?

Вы знаете об интересных нюансах. Кем работаете?

software engineer в Red Hat, имел два восхитительных года щастя ковыряния в деталях docker image

убрал селектор, но теперь другая проблема: I0215 10:04:41.388959 7 launch.go:94] &amp;{NGINX 0.9.0-beta.2 git-7013a52 git@github.com:ixdy/kubernetes-ingress.git} I0215 10:04:41.388989 7 launch.go:97] Watching for ingress class: nginx I0215 10:04:41.387575 7 nginx.go:112] starting NGINX process... I0215 10:04:41.390230 7 launch.go:223] Creating API server client for https://10.233.0.1:443 F0215 10:04:41.418959 7 launch.go:111] no service with name kube-system/default-http-backend found: services "default-http-backend" is forbidden: User "system:serviceaccount:kube-system:default" cannot get services in the namespace "kube-system" Вроде понятно что прав не хватает. Но где взять правильного юзера и как его прописать?

https://kubernetes.io/docs/admin/authorization/rbac/#kubectl-create-rolebinding

если нужно просто чтение сервисов, то view должно хватить

если нужно просто чтение сервисов, то view должно хватить

Я правильно понимаю что ошибка: services "default-http-backend" is forbidden: User "system:serviceaccount:kube-system:default" cannot get services in the namespace "kube-system" означает что юзеру "default" из неймспейса "kube-system" нужно навесить права?

https://github.com/kubernetes/ingress-nginx/blob/master/deploy/README.md#install-with-rbac-roles

Я правильно понимаю что ошибка: services "default-http-backend" is forbidden: User "system:serviceaccount:kube-system:default" cannot get services in the namespace "kube-system" означает что юзеру "default" из неймспейса "kube-system" нужно навесить права?

да

да

Выполнил вот такую команду(копипаста с доков с измененным юзером): kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=default --namespace=kube-system т.е я выдал права админа юзеру default из неймспейса kube-system

Но чет ошибка такая же при пересоздании ingress controller'a

вы как nginx ставили? Есть же внятная документация, берёте и тупо по шагам ставите

А можете дать линк на доку где по шагам все? Я ставил по этой статье с небольшими изменениями относительно того что приложение у меня это кеберовский дашборд и нет отдельных серверов для роутинга: https://dev-ops-notes.ru/kubernetes/kubernetes-%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-ingress/

А можете дать линк на доку где по шагам все? Я ставил по этой статье с небольшими изменениями относительно того что приложение у меня это кеберовский дашборд и нет отдельных серверов для роутинга: https://dev-ops-notes.ru/kubernetes/kubernetes-%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-ingress/

см. выше

дефолтный сервисаккаунт в kube-system не может читать сервисы в том же неймспейсе - и даже после добавления ему view? Тут что-то совсем сломалось

дефолтный сервисаккаунт в kube-system не может читать сервисы в том же неймспейсе - и даже после добавления ему view? Тут что-то совсем сломалось

если нету прав) то не может, обычно это решалось групповой политикой

Народ ,а есть какой-нибудь best practices для сбора логов? - настроил сервисы писать в /dev/stdout и /dev/stderr, через kubectl logs <pod_name> -c <container_name>все работает прекрассно, но есть ли какая-нибудь тулза которая через kubernetes-api будет подключаться и сохранять все это в какую-нибудь бд, и выводить через красивую веб-морду?

fluentd или filebeat и собирать с диска в эластик.

Народ ,а есть какой-нибудь best practices для сбора логов? - настроил сервисы писать в /dev/stdout и /dev/stderr, через kubectl logs <pod_name> -c <container_name>все работает прекрассно, но есть ли какая-нибудь тулза которая через kubernetes-api будет подключаться и сохранять все это в какую-нибудь бд, и выводить через красивую веб-морду?

в опеншифте дефолтно юзается EFK, но тут кто во что горазд

Да и что на счет ротации, я правильно понимаю что docker пишет все память без ротации и если логов будет много оно здохнет?

пишет куда скажут - дефолтно вроде в json-file

а что на счет ротации?

json-file можно по размеру ограничить, дефолно емнип 10 мб

но лучше конечно писать в systemd/rsyslog

https://docs.docker.com/config/containers/logging/configure/#configure-the-default-logging-driver

fluentd или filebeat и собирать с диска в эластик.

Надо настраивать сам сервис, что бы писал куда-то в директорию на хосте? - или можно fluentd на сам докер как-то натравить?

Хочется что бы и kubectl logs и морда показывали одно и тоже

Сделай ls /var/lib/docker/containers/*/*.log - увидишь логи от контейнеров на хосте

Есть еще /var/log/containers/ - там симлинки лежат

О, спасибо, добрый человек)

но лучше конечно писать в systemd/rsyslog

плюсы минусы подводные камни?

по сравнению с json-file в связке с fluentd

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

а потом уже фильтровать по контейнеру в эластике

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

То есть логика такая вполне приемлима? - Каждый сервис пусть пишет в stdout/stderr - А на каждой ноде fluentd настроенный на сбор логов из /var/lib/docker/containers/*/*.log и передает на центральный сервер логов

>Каждый сервис пусть пишет в stdout/stderr и никуда более

отлично!