

Andrey
07.03.2017
04:25:14
привет, я только начинаю разобираться со всем этим вот,
не знаю уместно ли тут задавать такие вопросы, но:
1) у меня на gcp крутится 2 кластера: production & staging (так вообще правильно делать?)
2) я испчерпал лимиты по внешним IP-адресам,
https://i.gyazo.com/d7dc959eeab7b29cb164e124a2125114.png
написано что нужно запросить дополнительно заполнив форму и ответ придет в течение пары дней примерно, что я и сделал. т.е. щас у меня сервисы висят с <pending> в колонке EXTERNAL-IP
https://i.gyazo.com/3bba807b7307cdb0d14f618cf765a76b.png
я ведь все правильно сделал? (: там в network чего-то многовато всего
3) мне досталось в наследство вот такое хозяйство со своими скриптами деплоя всего этого, выглядит вот так:
https://i.gyazo.com/1d1003ccff93da4b9db03a6f6443746e.png
это норма? вы так же делаете или как-то можно лучше все организовать?
4) разбираюсь с GCP, kubernetes прям вот основы схватил, научился более-менее пользоваться CLI инструментами их, поигрался с minikube, но пока сложновато все равно въезжать. а куча унаследованных скриптов делает этот процесс еще веселее. мб есть какой-то более-менее оптимальный прямой путь научиться?
вот это нашел https://github.com/kelseyhightower/kubernetes-the-hard-way, краткий курс на udacity, оф доки, что еще? ну и сорян за нубастые вопросы заранее)
Привет! Все хорошо. Ответ на все твои вопросы - да, все нормально и все хорошо. Научиться Kubernetes можно решая практические задачи, ища информацию в блогах и youtube. В интернете люди собирают что-то интересное про Kubernetes на awsome Kubernetes (зайди на awsome.re и там найди ссылку на Kubernetes). Только вчера пришла рассылка с новым курсом про Kubernetes (https://cloudacademy.com/cloud-computing/introduction-to-kubernetes-course/) с CloudAcademy, но сам я ее пока не смотрел.


Andrey
07.03.2017
07:52:59
а вот еще шняга на гугле
создаю сервис type=LoadBalancer, гугль соотвественно автоматом создает балансировщик дефолтный трафик с которого идет сразу на все ноды кластера
однако, почему-то до одной из нод трафон не доходит (роутинг выглядит норм, удалял ноду и пересоздавал новую - на другую тоже не идет)
если вручную к балансировщику добавляю проверку состояния - он сбойный инстанс исключает и все ок
но это ведь не вариант, да и tcp-проверку почему-то не могу добавить
вопрос: в какую сторону имеет смысл дебажить? роутинг там, или кто встречал че-то подобное

Max
07.03.2017
07:56:09
Я встречал и это был сбой гугла - но мне помогло удаление и пересоздание ноды

Andrey
07.03.2017
07:57:22
возможно, при пересоздании тот же самый сбой произошел... ок, попробую еще раз, спасибо :)

Google

Max
07.03.2017
07:59:07
Это кстати касается не только к8s а вообще - отсутвие связи это не то что бы норма но иногда бывает. У гугла там /32 и хостроутинг вроде бы


Andrey
07.03.2017
08:30:33
по гуглю вопрос еще если не возражаете :)
есть: эластиксерч на стейтфулсетах с подключением диска через volumeClaimTemplates
просто пристрелил под чтобы он перезапустился проверить как отработает, не может подмонтировать диск:
20m 1m 19 {kubelet gke-usa-default-pool-f9f11b36-f983} Warning FailedMount MountVolume.SetUp failed for volume "kubernetes.io/gce-pd/gke-usa-02f0a7ae-dynam-pvc-3e7559fb-f050-11e6-b19e-42010a80011c" (spec.Name: "pvc-3e7559fb-f050-11e6-b19e-42010a80011c") pod "2e748884-030d-11e7-b19e-42010a80011c" (UID: "2e748884-030d-11e7-b19e-42010a80011c") with: mount failed: exit status 32
Mounting command: mount
Mounting arguments: /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/gke-usa-02f0a7ae-dynam-pvc-3e7559fb-f050-11e6-b19e-42010a80011c /var/lib/kubelet/pods/2e748884-030d-11e7-b19e-42010a80011c/volumes/kubernetes.io~gce-pd/pvc-3e7559fb-f050-11e6-b19e-42010a80011c [remount]
Output: mount: cannot remount /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/gke-usa-02f0a7ae-dynam-pvc-3e7559fb-f050-11e6-b19e-42010a80011c read-write, is write-protected
есть идеи как разрулить?


Zon
07.03.2017
08:36:51


Andrey
07.03.2017
08:39:14
не, это в старых версиях было щас баг поправили
да даже если и с ним то слишком долго :)
NAME READY STATUS RESTARTS AGE
elasticsearch-elasticsea-0 0/1 Init:0/1 0 31m

Vasiliy
07.03.2017
10:25:38

Andrey
07.03.2017
10:27:30

Timur
07.03.2017
11:12:58
Привет. В чем реальное преимущество использования Rancher + Kubernetes по сравнению с чистым Kubernetes? Load balancing и там и там, UI тоже. Разве что настройка Kubernetes значительно проще через Rancher, и добавление/сетап нод. Есть какие-то ещё весомые плюсы?

Paul
07.03.2017
12:22:03
по мне - надумано

Konstantin
07.03.2017
12:45:11
Если не смотреть на то, что получается потом. То намного проще.
docker run, в гуе добавляешь ноду и говоришь, что она k8s. Конец.

Paul
07.03.2017
12:46:58

Google

Konstantin
07.03.2017
12:48:12
С этим согласен и возражений не имею)

Vasiliy
08.03.2017
01:11:46
хм, а как-то в google compute engine можно вообще понять почему не получается удалить группу инстансов? там 0 инстансов и вот сходу зависимостей вроде как нет насколько я вижу но
The deletion of the instance group failed. Error: The instance_group resource 'k8s-ig--8ef0639ec87559b5' is already being used by 'k8s-be-31293--8ef0639ec87559b5'
а сори) там же все написано в сообщении, бекенд же


Denis
09.03.2017
16:54:37
Интересно, а кто как организовал обновление K8s-конфигурация разработчиками?
1. Конфигурация подов/сервисов/секретов зависит от исходного кода сервисов (реп).
2. Состояние исходного кода между ветками + средами отличается (develop, stage, master, feature-ветки).
3. Допустим есть core-ветки: develop, stage, master, которые привязаны к поддоменам dev, stage и www соответственно.
4. Разработчики должны иметь возможность иметь возможность менять K8s-конфигурацию develop и feature-веток.
5. Деплой конфигурации должен быть автоматизирован через CI. При мердже кода k8s-конфигов develop => stage, stage => master также должны выкатывать соответствующие ветки с конфигурацией.
6. Каждая ветка feature-ветка должна пораждать новый поддомен, например: feature-123.dev.blablabla.com

Paul
09.03.2017
17:00:42
не очень понимаю конечную цель
но теоретически можно выдать разрабам неймспейс и ограничить доступ через ABAC

Denis
09.03.2017
17:05:03
Цель - автоматизация деплоя, автономность разработчиков и согласованность версий сервисов

Zon
09.03.2017
17:07:04
Деплой ветки в неймспейс, туда применяется конфигурация из ветки. Но это пока теория, на на практике не дошло.
сикреты хранятся отдельно, в самом к8с, стандартными средствами подставляются в конфигурацию

Artem
09.03.2017
17:13:28
можно все без кубернетеса сделать
зачем опять велосипед придумывать
нормально настроить дженкинс
или fabric8
или любой другой cicd
зачем разработчикам знать что то про кубернетис?

Denis
09.03.2017
17:15:23
Затем, чтобы инфраструктуру тюнинговать

Artem
09.03.2017
17:15:49
разработчикам?
это например как

Google

Artem
09.03.2017
17:16:06
они же не шарят
это работа админа или девопс

Denis
09.03.2017
17:16:32
Значит никто ещё не делал деплой на поддомены feature-*.dev.blablabla.com + удаление их через Х дней отсутствия активности?

Artem
09.03.2017
17:16:50
дженкинс все это делает
это должно решаться уровнем выше кубернетес
иначе разработчик на кошмарит такого, что век на разгребешь
ну либо у вас особенные разработчики
опиши пожалуйста, что значит тюнинговать окружение
может я просто неправильно понимаю

yolkov
09.03.2017
17:21:53
мы делаем
через хельм

Artem
09.03.2017
17:24:03
хельм это менеджер пакетов. а остальное на чем реализовано?
грубо говоря, что вместо дженкинса и ему подобных

yolkov
09.03.2017
17:25:08
CI конечно есть
хельм может хорошо шаблонизировать для разных сред
а дальше уже ваши фантазии на CI и конфигурации чартов

Artem
09.03.2017
17:27:13
кубернетес это бекенд для CI, эти все задачи - задачи CI


Denis
09.03.2017
17:28:00
Ок, ещё раз попробую) Может я просто неправильно как-то описал кейс.
Дано:
1. Есть набор реп, некоторые из них с одной веткой master, некоторые из них имеют ветки master, stage, develop. Некоторые ещё могут иметь ветки вида feature-425 (опционально).
2. Конфигурация K8s также в отдельной репе с ветками.
3. Некая абстрактная CI, которая может реагировать на git push.
Задача:
1. При деплое новой ветки, по заданным правилам разворачивать новый namespace и экземпляр сервисов. Правила включают имя поддомена и, опционально, - время жизни при отсутствии доступа (5 дней для feature-веток или бесконечно) и HTTP Basic Auth.
2. Например, если пушим в git ветку feature-425, то проверяем по каждой репе её наличие. Если есть - разворачиваем исходники оттуда, если нет - то из ветки develop.
3. Также можем запушить ветку feature-425 в репу с конфигурацией кубера (или удалить её из репы). В этом случае он обновит для заданного домена конфиг.
4. Выкатка в production будет заключаться в git merge веток develop => stage и затем stage => master для всех реп.


Artem
09.03.2017
17:29:09
^^ ну вот бери дженкинс и настраивай) все это уже давно придумано и работает

Denis
09.03.2017
17:29:23
Есть пруф-ссылки?)

Google

yolkov
09.03.2017
17:30:33
сами флоу придумываем, какие ссылки)

Artem
09.03.2017
17:30:39
есть слайдов тонна, ссылки-то вряд-ли.
кубернетес тут вообще не причём, он тут как оркестратор виртуалок

Max
09.03.2017
17:31:57
на груви dsl наверно можно закодить обернув git ... в try .. except а в целом кубернетес тут не при делах

Artem
09.03.2017
17:32:23
настройка сервиса это докер файл обычный

yolkov
09.03.2017
17:33:04
вот простой флоу
- в Ci клонируешь код, клонируешь конфигурации для куба, если будет конфигурации в виде хельм чарта, то твои параметры для разных сред записываешь в соответсвующие файлы
- Билдишь проект
- пушишь в регистри
- создаешь неймспейс например по номеру в трекере
- поднимаешь окружение
…
- тригеришься на удалении ветки из VCS и удаляешь неймспейс

Artem
09.03.2017
17:33:09
сам кубернетес настраивать - ну это точно не разработчиков задача
ну или так, да
да и неймспейсы тут имхо лишнее совсем

yolkov
09.03.2017
17:34:35
удобно
только права выдавать полные приходится выдавать для CI, что не хотелось бы, хотя надо попробовать их динамически создавать если РБАК заюзать

Artem
09.03.2017
17:36:32
namespace нужен когда больше десятка юзеров и нет договорённости по неймингу
а когда один cicd то неймспейс лишняя сущность

yolkov
09.03.2017
17:38:09
неймспейсы удобны когда имеешь дело с многокомпонентными проектами и использованием одновременно несколько копий этого приложения
либо придется дико шаблонизировать все, добавлять префиксы и т.п. чтобы сосуществовать в одном неймспейсе

Zon
09.03.2017
17:39:22

Artem
09.03.2017
17:39:39
ну то есть лень настроить дженкинс, настроим кубернетис)

yolkov
09.03.2017
17:40:05
несогласен

Artem
09.03.2017
17:41:17
ну плодить сущности без необходимости тоже идея так себе.
потом когда-нибудь придётся удалять домен 15 уровня

Google

Zon
09.03.2017
17:42:07
Дженкинсово дело настроить 1 неймспейс, а какой именно это будет неймспейс - зависит от ветки. Пихать всё в один не вижу смысла

yolkov
09.03.2017
17:42:24
например в проекте, есть кластер редисов, мемкешей, можно будет создавать деплойменты и префиксировать его например по номеру таска.
а можно запрефиксировать только главное приложение(по которому заходим в приложение), а остальные имена будут дефолтные redis-cluster, memcache-cluster и т.п.
конфиг для приложения тоже менять не придется

Artem
09.03.2017
17:42:58
согласен, тут от ТЗ зависит многое

yolkov
09.03.2017
17:42:59
а в твоем варианте его генерить придется

Zon
09.03.2017
17:43:39
Менять неймспейс проще, чем конфиги

Artem
09.03.2017
17:44:11
CI в опенстек например, работает без неймспейсов, а там больше ста компонентов

yolkov
09.03.2017
17:44:40
@DenisIzmaylov на следующем митапе наши вроде хотели рассказать про хельм немного

Artem
09.03.2017
17:44:58
всё разделение по логике на уровне дженкинса и его неймспейсов

Zon
09.03.2017
17:45:00
100 компонентов * Х версий параллельно?

Artem
09.03.2017
17:45:16
да
но у них ещё есть зуул некий

yolkov
09.03.2017
17:46:31
да все можно. Но я про реальную ситуацию говорю, вот мы сели, попробовали просто пошаблонизировать наши конфиги для куба, охерели, попробовали хельм, стало лучше. А потом решили по нейспейсам поделить и стало еще лучше)

Artem
09.03.2017
17:48:49
просто потом мало понятно становится, где чья ответственность и кто где что настраивает.
всё друг другу пишут тексты и CI неделю в коме