Блин, чуваки, в доке кубов есть замечательная инструкция как поднять кластер на bare-metal с kubeadm, у меня он завелся с полпинка, что вы блять чудите?

Блин, чуваки, в доке кубов есть замечательная инструкция как поднять кластер на bare-metal с kubeadm, у меня он завелся с полпинка, что вы блять чудите?

kubeadm все еще не парится по поводу auth и не генерит серты для всего?

не судите строго, я в процессе изучения этих технологий по документации CoreOS я не вижу зависимости создания кластера от Kubernetes у CoreOS свой мастер с etcd, вот тут прочитал: https://coreos.com/os/docs/latest/cluster-architectures.html

нету у кореос своего кластера.

окромя tectnonic

kubeadm все еще не парится по поводу auth и не генерит серты для всего?

Серты конечно генерятся, а про auth не понял

окромя tectnonic

и тот на кубере сделан

Серты конечно генерятся, а про auth не понял

я с 1.7 пробовал kubeadm, он тогда не парился вообще о том чтобы уровень безопасности в кластере был хотя бы минимальным

нету у кореос своего кластера.

спасибо, уже прочитал на сайте CoreOS: Most of these scenarios dedicate a few machines, bare metal or virtual, to running central cluster services. These may include etcd and the distributed controllers for applications like Kubernetes, Mesos, and OpenStack.

я с 1.7 пробовал kubeadm, он тогда не парился вообще о том чтобы уровень безопасности в кластере был хотя бы минимальным

а что именно не так было?

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

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

вот это тоже вопросы вызывает.

а что именно не так было?

я помню что без сертов мог тыкать в etcd

а

надо проверить, у меня как раз есть кластер из kubeadm

тогда другой вопрос: в чем преимущество "CoreOS + Kubernetes" над "Другой Linux + Kubernetes"?

тогда другой вопрос: в чем преимущество "CoreOS + Kubernetes" над "Другой Linux + Kubernetes"?

CoreOS не позволяет ставить софт и превращать хост в помойку

ну это больше человеческий фактор конечно )

хотя я понимаю, что это плюс

а что еще?

атомарные апдейты

ОС типа Atomic/CoreOS удобны для больших инсталляций с динамическим поднятием и выкидыванием машинок. Они под это разрабатывались

ну я пока для старта хочу использовать 2 хоста, позже уже добавлять хосты для производительности и настройки отказоустойчивости

поэтому и возникло сомнение, или не перебор сразу использовать CoreOS

можно и coreos. Я его на домашнем серваке использую, в single host k8s cluster'е

но если вам нужен именно кластер, то долго думать над выбором ОС не стоит, берите наиболее привычную вам. Но не centos, говорят там проблемы с k8s :)

остаётся ubuntu/debian/w2k19

alpine?

alpine на хосте?

ну чтоб места много не жрал =)))

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

ну я реальных применений alpine на хосте не видел

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

кажется весь дистрибутив будет меньше весить, чем два бинарника kubelet+docker

но если вам нужен именно кластер, то долго думать над выбором ОС не стоит, берите наиболее привычную вам. Но не centos, говорят там проблемы с k8s :)

Скорее с Docker из-за старого ядра.

alpine?

нене. компилировать замучаетесь

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

Почему бы не сказать прямо, что там musl вместо glibc (по умолчанию)? ?

мастером я назвал "etcd-машину" ))

Запускайте etcd там же где и apiserver

тогда другой вопрос: в чем преимущество "CoreOS + Kubernetes" над "Другой Linux + Kubernetes"?

У CoreOS посвежее ядро и внутри все встроено для контейнеров и Kubernetes. Еще у них есть киллер фича Ignition, что-то вроде cloud-init, но который работает нормально, позволяет всю конфигурацию хоста описать одним json файлом. Хорошо работает в паре с их же matchbox, который может генерировать это ignition файлы на лету из ваших темплейтов

?

я помню что без сертов мог тыкать в etcd

у меня так же. А насколько это критично? Он слушает на 127.0.0.1 и только с хоста доступен

у меня так же. А насколько это критично? Он слушает на 127.0.0.1 и только с хоста доступен

Не может быть, а как другие APIserver ходят в etcd?

У CoreOS посвежее ядро и внутри все встроено для контейнеров и Kubernetes. Еще у них есть киллер фича Ignition, что-то вроде cloud-init, но который работает нормально, позволяет всю конфигурацию хоста описать одним json файлом. Хорошо работает в паре с их же matchbox, который может генерировать это ignition файлы на лету из ваших темплейтов

Для поднятия руками cloud-init так себе преимущество. Для matchbox нужны дополнительные машинки и окружение

Не может быть, а как другие APIserver ходят в etcd?

single master

kubeadm вроде как не умеет multimaster

Для поднятия руками cloud-init так себе преимущество. Для matchbox нужны дополнительные машинки и окружение

Отличное преимущество, вся возня руками автоматически попадает в код , ибо другого пути нет. Ignition файл можно класть на любой http сервер и просто ребутать ноду после правок

ignition только раз отрабатывает

first boot

ignition только раз отрабатывает

Нет. Оно кладет файл флаг , можно его удалять и ребутать

и всё переставляет с нуля? Хм

В этом и соль. "все переставляет" занимает секунд 40 :) зато всегда предсказуемый результат

А не так, что долбим ансибл пока все не заработает, но потом на чистом хосте "рабочий" ансибл все равно ломается на пол пути

Для системы с одним воркером это не вариант :)

state весь теряется

Можете не форматировать data volume

Ignition умеет "форматировать, только если еще не отформатированно"

А не так, что долбим ансибл пока все не заработает, но потом на чистом хосте "рабочий" ансибл все равно ломается на пол пути

ну эт ты загнул кнчно =) а с какого объема машин думаешь есть смысл пересаживаться на coreos и его плюшки? прост у меня мини кластера в разных дц

это, конечно, интересно. Но у меня всё равно только один сервак.

ну эт ты загнул кнчно =) а с какого объема машин думаешь есть смысл пересаживаться на coreos и его плюшки? прост у меня мини кластера в разных дц

Я не уверен в будущем CoreOS :)

это, конечно, интересно. Но у меня всё равно только один сервак.

Даже с одним серваком хочется иметь повторяемый результат своих действий. Чтобы можно было 1 превратить в 11 малой кровью

у меня для этого есть k8s. Поверх чего он стоит, debian или coreos - не так важно.

но аргументы я понял

у меня сервак лежит на кухне на холодильнике, и ещё 10 я туда впихивать не собираюсь :)

Для приложений да, но сам k8s поднять нетривиально и хочется все эти прыжки иметь в коде , чтобы сделал один раз и забыл, только версии image поднимать, да новые AdmissionControllers прописывать

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

и этот флаг ставишь ты сам своими кривыми ручками

нафиг-нафиг. Я ещё бэкапы не настроил

Для поднятия руками cloud-init так себе преимущество. Для matchbox нужны дополнительные машинки и окружение

matchbox для простого кластера я так понял, что не нужен? или без него kubernetes на CoreOS не поднять?

matchbox нужен для установки tectonic

а так можно minikube/kubeadm/kubespray использовать

ок, tectonic пока не планирую разворачивать

Привет ребят. У меня возможно глупый вопрос, но не смог быстро нагуглить. Как сервисам из миникуба позволить стучать на хост машину к локальным адресам?

контекст - поднят php инстанс с локальным веб сервером на 127.0.0.1:8000 и сервис должен достучатся до него

0.0.0.0?

контекст - поднят php инстанс с локальным веб сервером на 127.0.0.1:8000 и сервис должен достучатся до него

ну на 127.0.0.1 ты не попадёшь

нужно слушать или 0.0.0.0. или подсеть твего cni

нужно слушать или 0.0.0.0. или подсеть твего cni

ок. Это слушает

юзать 10.0.2.2 законно?

100.0.2.2 надо юзать

100? Это же не нат сеть? каким макаром адрес стал 100?

да это так, с прошлой работы воспоминания

юзать 10.0.2.2 законно?

зависит от твоего законодательства и религии. ну тогда пробуй подключаться к 10.0.2.2:8000

зависит от твоего законодательства и религии. ну тогда пробуй подключаться к 10.0.2.2:8000

спасибо

только странно что 10,0,2,2, я думал что на 1 обычно хост заканчивается, ведь это какбы шлюз для подов других

Добрый день! Разворачивал k8s на площадке отличной от GCE и аозможно не совсем правильно отключал RBAC для Ci Runner ( https://gitlab.com/gitlab-org/gitlab-runner/issues/2130 ) sh-3.2# kubectl get pods NAME READY STATUS RESTARTS AGE gitlab-gitlab-5dcd88959d-6nwr2 0/1 ContainerCreating 0 10m gitlab-gitlab-postgresql-5fff4f67bb-zqgxx 0/1 ContainerCreating 0 10m gitlab-gitlab-redis-6c88945d56-pw5xm 0/1 ContainerCreating 0 10m gitlab-gitlab-runner-5fc8656997-x86h5 0/1 CrashLoopBackOff 6 10m sh-3.2# kubectl log gitlab-gitlab-runner-5fc8656997-x86h5 W0403 18:54:28.738278 12393 cmd.go:353] log is DEPRECATED and will be removed in a future version. Use logs instead. + cp /scripts/config.toml /etc/gitlab-runner/ + /entrypoint register --non-interactive --executor kubernetes Running in system-mode. ERROR: Registering runner... failed runner=tQtCbx5U status=couldn't execute POST against http://gitlab-gitlab.default:8005/api/v4/runners: Post http://gitlab-gitlab.default:8005/api/v4/runners: dial tcp 10.233.49.219:8005: i/o timeout PANIC: Failed to register this runner. Perhaps you are having network problems sh-3.2# kubectl describe pod gitlab-gitlab-runner-5fc8656997-x86h5 ... Labels: app=gitlab-gitlab-runner pod-template-hash=1974212553 Annotations: <none> Status: Running IP: 10.233.68.51 Controlled By: ReplicaSet/gitlab-gitlab-runner-5fc8656997 Containers: gitlab-gitlab-runner: Container ID: docker://0daccbc35e1eb67be885870bb60bc416f949254b21a774233c2169e4d177713e Image: gitlab/gitlab-runner:alpine-v10.3.0 Image ID: docker-pullable://gitlab/gitlab-runner@sha256:9b1e53a91fc8914c934b9eacf93365c7af97d97514c71b1825f677c8ee2a2369 Port: <none> Command: /bin/bash /scripts/entrypoint State: Waiting Reason: CrashLoopBackOff Last State: Terminated Reason: Error Exit Code: 1 Started: Tue, 03 Apr 2018 18:51:52 +0300 Finished: Tue, 03 Apr 2018 18:52:22 +0300 Ready: False Restart Count: 6 Liveness: exec [/usr/bin/pgrep gitlab.*runner] delay=60s timeout=1s period=10s #success=1 #failure=3 Readiness: exec [/usr/bin/pgrep gitlab.*runner] delay=10s timeout=1s period=10s #success=1 #failure=3 Environment: CI_SERVER_URL: http://gitlab-gitlab.default:8005/ CI_SERVER_TOKEN: <set to the key 'runner-token' in secret 'gitlab-gitlab-runner'> Optional: false REGISTRATION_TOKEN: <set to the key 'runner-registration-token' in secret 'gitlab-gitlab-runner'> Optional: false KUBERNETES_IMAGE: ubuntu:16.04 KUBERNETES_PRIVILEGED: true KUBERNETES_NAMESPACE: default ...Conditions: Type Status Initialized True Ready False PodScheduled True Volumes: var-run-docker-sock: Type: HostPath (bare host directory volume) Path: /var/run/docker.sock HostPathType: scripts: Type: ConfigMap (a volume populated by a ConfigMap) Name: gitlab-gitlab-runner Optional: false default-token-pzl9n: Type: Secret (a volume populated by a Secret) SecretName: default-token-pzl9n Optional: false QoS Class: BestEffort Node-Selectors: <none> Tolerations: <none> Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 12m default-scheduler Successfully assigned gitlab-gitlab-runner-5fc8656997-x86h5 to k8s-node2.gettransfer.cz

Normal SuccessfulMountVolume 12m kubelet, k8s-node2.gettransfer.cz MountVolume.SetUp succeeded for volume "var-run-docker-sock" Normal SuccessfulMountVolume 12m kubelet, k8s-node2.gettransfer.cz MountVolume.SetUp succeeded for volume "default-token-pzl9n" Normal SuccessfulMountVolume 12m kubelet, k8s-node2.gettransfer.cz MountVolume.SetUp succeeded for volume "scripts" Normal Started 10m (x4 over 12m) kubelet, k8s-node2.gettransfer.cz Started container Normal Pulled 9m (x5 over 12m) kubelet, k8s-node2.gettransfer.cz Container image "gitlab/gitlab-runner:alpine-v10.3.0" already present on machine Normal Created 9m (x5 over 12m) kubelet, k8s-node2.gettransfer.cz Created container Warning BackOff 2m (x34 over 11m) kubelet, k8s-node2.gettransfer.cz Back-off restarting failed container Коллеги, как быть? Кто сталкивался с деплоем Gitlab Ci средствами helm на bare-metal servers? в чем может быть причина? Может дело в RBAC и если да, то как его отключить "глобально" Спасибо

gitlab-gitlab-5dcd88959d-6nwr2 0/1 ContainerCreating 0 10m у вас еще сам гитлаб не поднялся, похоже

@vrutkovs да, не могу понять в чем проблема. Ошибки меняются в ходе replase RBAC для helm а

@vrutkovs да, не могу понять в чем проблема. Ошибки меняются в ходе replase RBAC для helm а

читайте events в самому гитлабу

А зачем отключать rbac для gitlab-runner?

Я запускал с rbac: https://gitlab.com/charts/charts.gitlab.io/blob/master/charts/gitlab-runner/values.yaml ## For RBAC support: rbac: create: true