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] &{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] &{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 и никуда более

отлично!

Ребят, создал по доке биндинг: kubectl create clusterrolebinding myapp-view-binding --clusterrole=admin --serviceaccount=kube-system:default но при деплое ингресс всеравно ошибка: E0215 10:50:01.816540 7 reflector.go:199] k8s.io/ingress/core/pkg/ingress/controller/controller.go:1037: Failed to list *api.Node: nodes is forbidden: User "system:serviceaccount:kube-system:default" cannot list nodes at the cluster scope какие ему еще то права нужны?

а роль то есть такая?

она вроде "cluster-admin"

А CRI-O какие варианты предлагает по логам кстати?

она вроде "cluster-admin"

спасибо, похоже вы правы)

А CRI-O какие варианты предлагает по логам кстати?

text или json

в файл?

или там плагины