Как то так вроде бы

The shortcut http://localhost:8001/ui is deprecated. Use the full proxy URL shown above. https://github.com/kubernetes/dashboard/blob/master/README.md

пытаюсь на него войти https://ip_master:6443/ui

Что значит "на него"? Куда ты хочешь войти?

дашборд

Connecting to Kubernetes By default, Kubespray configures kube-master hosts with insecure access to kube-apiserver via port 8080. A kubeconfig file is not necessary in this case, because kubectl will use http://localhost:8080 to connect. The kubeconfig files generated will point to localhost (on kube-masters) and kube-node hosts will connect either to a localhost nginx proxy or to a loadbalancer if configured. More details on this process are in the HA guide. Kubespray permits connecting to the cluster remotely on any IP of any kube-master host on port 6443 by default. However, this requires authentication. One could generate a kubeconfig based on one installed kube-master hosts (needs improvement) or connect with a username and password. By default, a user with admin rights is created, named kube. The password can be viewed after deployment by looking at the file PATH_TO_KUBESPRAY/credentials/kube_user. This contains a randomly generated password. If you wish to set your own password, just precreate/modify this file yourself. For more information on kubeconfig and accessing a Kubernetes cluster, refer to the Kubernetes documentation. Accessing Kubernetes Dashboard If the variable dashboard_enabled is set (default is true) as well as kube_basic_auth (default is false), then you can access the Kubernetes Dashboard at the following URL: https://kube:_kube-password_@_host_:6443/ui/ To see the password, refer to the section above, titled Connecting to Kubernetes. The host can be any kube-master or kube-node or loadbalancer (when enabled). To access the Dashboard with basic auth disabled, follow the instructions here: https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/#command-line-proxy

Бля, ну зачем было засерать вывод?

У тебя вообще kubernetes-dashboard сервис поднят?

да

kube-system kubernetes-dashboard-7fd45476f8-wxvc4 1/1 Running 0

ты kubectl на локалхосте установил?

с мастер сервера работаю

Поставь локально kubectl, потом сделаешь kubectl proxy — пробросишь себе все нужные порты на локалхост.

И уже тогда можешь идти по ссылке, которую выше давали.

опааа. А чтобы отовсюду доступ к панели был что надо ковырнуть?

https://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/

опааа. А чтобы отовсюду доступ к панели был что надо ковырнуть?

чтобы зайти на db нужно, либо настроить RBAC, либо настроить админский доступ для всех https://github.com/kubernetes/dashboard/wiki/Access-control

https://github.com/kubernetes/dashboard/wiki/Access-control#official-release

Чтобы зайти на панель с других адресов, посмотри какой у неё адрес kubectl get svc -n kube-system

По адресу, который там увидишь, зайди по https

Только там сертификат будет корявый, заходи FireFox'ом

ClusterIP идет в Type

и не доступен через браузер

kubernetes-dashboard ClusterIP 10.233.18.218 <none> 80/TCP

kibana-logging ClusterIP 10.233.41.132 <none> 5601/TCP

Просто зайди на дэшборд через прокси, не канифоль мозги. Если мы так будем настраивать тебе, то дойдем до настройки твоего домашнего роутера, для доступа в сеть 10.233/16

ок))

ну можно сделать тип сервиса NodePort

и тогда дашбоард покажется на ip ноды на каком то порту

кстати это довольно легок) нужно указать сеть 10.233.0.0/16 с гетвеем = ноде кубера с kube-proxy

кстати это довольно легок) нужно указать сеть 10.233.0.0/16 с гетвеем = ноде кубера с kube-proxy

Это да, просто вопрошающий, совсем примитивов кубика не знает, поэтому ему там еще до NodePort и LoadBalancer далековато.

У меня не возможен LoadBalancer

На безрыбье NodePort сойдет, если у тебя нет трех тысяч служб, конечно (-:

Ты можешь готовить образы для кубика через ansible-container

докер настолько живет своей жизнью, что остальные вендоры за ним часто не поспевают. Очень высокий риск нарваться на спефицические баги (ansible - docker). мы пробовали, исплевались.

докер настолько живет своей жизнью, что остальные вендоры за ним часто не поспевают. Очень высокий риск нарваться на спефицические баги (ansible - docker). мы пробовали, исплевались.

Я бы не сказал, что все так плохо, надо просто смотреть на совместимость в аннотациях и понимать что ты хочешь сделать, это же всего лишь обертка.

докер настолько живет своей жизнью, что остальные вендоры за ним часто не поспевают. Очень высокий риск нарваться на спефицические баги (ansible - docker). мы пробовали, исплевались.

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

докер настолько живет своей жизнью, что остальные вендоры за ним часто не поспевают. Очень высокий риск нарваться на спефицические баги (ansible - docker). мы пробовали, исплевались.

Нарваться можно не только на ansible, но и на CentOS+firewald+docker = вместе оно не живёт без влома :)

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

на текущий момент в k8s деплоим при помощи ansible (генерация манифестов) и дженкинс.

Нарваться можно не только на ansible, но и на CentOS+firewald+docker = вместе оно не живёт без влома :)

docker и firewalld главная причина существования rkt и cri-o

docker и firewalld главная причина существования rkt и cri-o

Да, будем переходит на CRI-O как полностью стабилизируется, имею ввиду билд, хранение

Да, будем переходит на CRI-O как полностью стабилизируется, имею ввиду билд, хранение

Ну я бы не стал торопиться, я уверен что в будущем починят, а для докера сейчас столько всего, что cri-o точно не конкурент.

К тому же это не такая уж проблема, коль уж скоро, мы в сообществе k8s об этом говорим.

Ну я бы не стал торопиться, я уверен что в будущем починят, а для докера сейчас столько всего, что cri-o точно не конкурент.

Да при ориентире на k8s докер нужен как простая обёртка, даже всё равно какой он там версии. Отдельно докер у нас практически сейчас не используется, микросервисы все имеют from sratch image

про проблему firewald и docker говорили еще год назад, но пока не сдвинулось

А OpenShift не хотите?

хотим, но не все потянут, штат небольшой

Насколько я понял, он только с докером нормально работает.

кстати, вот интересный вопрос, что лучше from scratch или alpine + запуск приложения от юзера )

ну и с провайдера съезжать надо, у нас CloudStack

кстати, вот интересный вопрос, что лучше from scratch или alpine + запуск приложения от юзера )

Безопаснее, в проде однозначно from scratch, зачем нам юзер в контейнере с правами рута

Я вот сейчас пытаюсь поднять OpenShift в надежде упростить назначение PersistentVolume'ов

Это главная причина, но еще есть у него плюшки при интеграции с OpenStack

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

был бы у провайдера OpenStack - не вопрос

Так или иначе, вникать надо глубоко (-:

А то будешь задавать вопросы, типа: "А как зайти на дэшборд?"

на текущий момент в k8s деплоим при помощи ansible (генерация манифестов) и дженкинс.

а можно немного подробнее? если не сложно - то небольшой пример будет вообще идеальным. У дженкинса же через pipeline делаете?

Безопаснее, в проде однозначно from scratch, зачем нам юзер в контейнере с правами рута

почему с правами рута? если в Dockerfile укзан user guest то на хосте этот процесс будет виден не как от рута.

а можно немного подробнее? если не сложно - то небольшой пример будет вообще идеальным. У дженкинса же через pipeline делаете?

ну самое первое, это нужно собрать имедж. Для этого в репозиторий с проектом(сервисом) можно положить Dockerfile, Makefile, т.е. все необходимое для сборки. На этом же этапе можно делать и тесты, вплоть до интеграционных. Т.е. подняли необходимые сайд-контейнеры, развернули структуру базы, прогнали тесты, если все ок - тогда собранный имедж уже пушим в реджистри. (вариантов много, от своего до docherhub и bintray). Собирать тоже можно любым CI, хоть дженкинсом, хоть travis-ci. Здесь имхо, главное чтобы сборка была описана в Makefile, тогда переход между любой системой CI достаточно безболезнен. После того как у нас где то есть имедж в реджистри, его можно деплоить в различные среды. Здесь как удобно, кто-то использует helm, для самых простых кейсов и kubectl напрямую подойдет. У меня исторически используется ansible, поэтому в репозитории лежат темплейты сервисов. деплой через ансибл - это просто вызов плейбука в духе ansible-playbook -i environments/dev echoserver.yml Но если вы малознакомы с ансиблом, я бы посоветовал начать просто с plain kubectl манифестов, дабы не забивать мозг лишним.

ну самое первое, это нужно собрать имедж. Для этого в репозиторий с проектом(сервисом) можно положить Dockerfile, Makefile, т.е. все необходимое для сборки. На этом же этапе можно делать и тесты, вплоть до интеграционных. Т.е. подняли необходимые сайд-контейнеры, развернули структуру базы, прогнали тесты, если все ок - тогда собранный имедж уже пушим в реджистри. (вариантов много, от своего до docherhub и bintray). Собирать тоже можно любым CI, хоть дженкинсом, хоть travis-ci. Здесь имхо, главное чтобы сборка была описана в Makefile, тогда переход между любой системой CI достаточно безболезнен. После того как у нас где то есть имедж в реджистри, его можно деплоить в различные среды. Здесь как удобно, кто-то использует helm, для самых простых кейсов и kubectl напрямую подойдет. У меня исторически используется ansible, поэтому в репозитории лежат темплейты сервисов. деплой через ансибл - это просто вызов плейбука в духе ansible-playbook -i environments/dev echoserver.yml Но если вы малознакомы с ансиблом, я бы посоветовал начать просто с plain kubectl манифестов, дабы не забивать мозг лишним.

Вот у меня сейчас как раз через kubectl напрямую идёт. С ansible действительно знаком мало. Но учитывая что разворачивание кластера шло через него - хочется разобраться :) Просто как я понял ansible больше оперирует состояниями. Т.е. мы ждем что у нас будет установлено такое то приложение. И если это не так - ansible это исправляет. Но вот как ему сказать что я жду что у меня должно быть развернуто приложение в кубере через него - я пока не очень понимаю. Впрочем это думаю можно подсмотреть в самом kubespray. А вот как например удалить уже не нужное приложение через ansible - я вообще не понимаю

ансибл это просто обертка для удобства.

он не делает ничего умного. - name: Apply kubectl configuration for application {{ app_name|upper }} shell: "kubectl apply -f {{ template_path }}/{{ app_name }}.yml"

сейчас трендовым является использование helm для этих задачь

Хм... т.е. по сути все приложения так же должны быть прописаны в самом yaml кубера?

Мне helm мозг лосмал. Он не работает. Как мне сказали - он в моей версии кубера багнутый. А как его через тот же ansible(kubespray) переустановить - я не понимаю пока

да. плюс в том что yaml генерится динамически ансибл, с учетом переменных для разных окружений (staging\development и т.д.)

Эм... как yaml генерится ansibl'ом? Ведь у вас там просто выполнение этого yaml файла выше? Т.е. до этого его уже сгенерили?

http://docs.ansible.com/ansible/latest/template_module.html

Спасибо, но пока не очень понятно как такое приводится к виду yaml файла который кушает kubectl

Эм... как yaml генерится ansibl'ом? Ведь у вас там просто выполнение этого yaml файла выше? Т.е. до этого его уже сгенерили?

ну как бы j2 темплейты....с ними работает ansible .подставляет в нужные места переменные

Хм.. видимо я пока мало доков прочитал на эту тему. В любом случае большое спасибо за помощь. Буду разбираться дальше :)

почему с правами рута? если в Dockerfile укзан user guest то на хосте этот процесс будет виден не как от рута.

Вы про RUN и CMD - по сути не важно под каким юзером вы билдите слои, оно важно для сервисов с нерутовым юзером. Речь идёт о docker exec

Всем привет, ищу можно ли c k8s поднимать контейнеры on demand, и если они проставивают выгружать соответсвенно, занятно что в инете почти ничего нет - https://stackoverflow.com/questions/36379436/implement-on-demand-docker-container-start-up . Это вообще можно сделать?

@lapanoid https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

про Horizontal Pod Autoscaling пишут but there's no built-in functionality for 0-to-1 scaling on receiving a request, and I'm not aware of any widely used solution.

Ну а что тебе не нравится? Пишут что нет системы автоскелинга с 0 до 1

а вот дальше легко

в обе стороны. Это чем то напоминает DRS. Кубер через heapster наблюдае за нагрузкой, и когда текущая нагрузка превышает установленные процент от лимита, запускаете ище один под, и включает его в сервис, и так до тех пор, пока не достигнит предела по hpa либо пока нагрузка не устаканится

Так мне оно и надо с 0 до 1

именно это и надо

по идее легко реализуемо через ingress) по крайней мере костылем)