надо работать с сервисами внутри кластера и общаться с сервисом через svc.namespace.cluster.local

если вдаваться в детали, есть продукт-монолит, котрый по частям перевозят в кубер. В будущем всё это будет вариться внутри кубера и проблем не будет. В промежуточный период надо несмигрированной части продукта общаться со смигрированной, которая уже в кубере.

подскажите способ(ы) подсоединять внешний сервер, находящийся в одной приватной сети с кластером, ко внутренним сервисам в cluster.local. На данный момент мне предлагается: а) пробросить маршрут через: ip route add 10.96.0.0/12 via <IP адрес ноды кластера> б) добавить в /etc/resolv.conf: nameserver 10.96.0.10 Это работает, но мне не нравится такой костылизм.

руками добавить сервис с эндпоинтами?

сервис для чего?

так, для dns нарыл решение через dnsmasq: https://blog.heptio.com/configuring-your-linux-host-to-resolve-a-local-kubernetes-clusters-service-urls-a8c7bdb212a7 для роутинга наверное такое простое решение не получится

а то выглядит со стороны как будто вы хотите соединить из разных куб-кластеров в вебе и в локалке один и тот же сервис))

есть два приложения, одно в кубе, другое нет. Мне их надо связать так, чтоб приложение, которое не в кубе, сразу обращалось по svc.namespace.cluster.local. Вроде же расписал выше.

есть два приложения, одно в кубе, другое нет. Мне их надо связать так, чтоб приложение, которое не в кубе, сразу обращалось по svc.namespace.cluster.local. Вроде же расписал выше.

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

да, именно так

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

и оно рассчитывает на сервис дискавери и прямой доступ в сеть кубера

а поскольку переходный период затягивается, нужно относительно надёжное решение, а не тупой маршрут через IP адрес одной ноды кластера

не представляю как они его пишут, по завету 12-факторов, оно должно с пол-пинка и там и там заводиться, лишь конфиг должен изменяться

это древнее энтерпрайзнутое говно мамонта, там не всё так быстро

самые простые вещи типа ui перевезли, а ядро ещё нет, и ещё не скоро

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

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

Нет

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

Если вы ищете человека, то вам сюда @devops_jobs

С ceph замучался, не могу его поднять на centos7 Если есть проверенное решение, поделитесь ссылочкой. Уже все варианты перепробовал...

Ceph поднимал на виртуалках. Сейчас буду пробовать в докере запускать

Ceph поднимал на виртуалках. Сейчас буду пробовать в докере запускать

Я как раз на пороге сего действия - в чем там случилась проблема?

закончилось както так ceph-deploy purgedata c7gfs02 c7gfs03 c7vmw04 c7vmw05 c7vmw06 ceph-deploy forgetkeys ceph-deploy purge c7gfs02 c7gfs03 c7vmw05 c7vmw06 c7vmw04 ceph-deploy purge $(hostname -s) ceph-deploy purgedata $(hostname -s) sudo rm -rf /etc/ceph/* sudo rm -rf /var/lib/ceph/*/* sudo rm -rf /var/log/ceph/* sudo rm -rf /var/run/ceph/*

ceph в докере да вы оптимист

да? опять потерянное время? ставил эту версию, не пошла ceph-deploy install --release mimic

всем привет, а по Helm тоже сюда можно вопросы задавать?

всем привет, а по Helm тоже сюда можно вопросы задавать?

задавай

да? опять потерянное время? ставил эту версию, не пошла ceph-deploy install --release mimic

Хм.. rook.io возможно спасёт вас)

Хм.. rook.io возможно спасёт вас)

а чем лучше minio.io, отзыв не дадите?

а чем лучше minio.io, отзыв не дадите?

Rook оркестратор для кластера)

Rook оркестратор для кластера)

а в целом, по функционалу

надо работать с сервисами внутри кластера и общаться с сервисом через svc.namespace.cluster.local

https://hackernoon.com/locally-developing-kubernetes-services-without-waiting-for-a-deploy-f63995de7b99 посмотри во тут, может подойдет

а чем лучше minio.io, отзыв не дадите?

Minio конкурент ceph’a

https://hackernoon.com/locally-developing-kubernetes-services-without-waiting-for-a-deploy-f63995de7b99 посмотри во тут, может подойдет

спс, посмотрю

Minio конкурент ceph’a

а лол, рук для кубера я себе для петпроджектов ищу сторэдж обьектный шобы под композ поставить

спс, посмотрю

Там правда больше про дев. Прод как правильно сказали через сервисы экспозить.

https://hackernoon.com/locally-developing-kubernetes-services-without-waiting-for-a-deploy-f63995de7b99 посмотри во тут, может подойдет

Хорошая штука, telepresence - запускать часть кластера .. на локальной машине разработчика ))) бомбично)

Хорошая штука, telepresence - запускать часть кластера .. на локальной машине разработчика ))) бомбично)

Ага

а лол, рук для кубера я себе для петпроджектов ищу сторэдж обьектный шобы под композ поставить

Ну да https://github.com/rook/rook/blob/master/README.md

Бесшовный remote dev env на кубере для микросервисов, и не только.

вопрос такой: пробую сварить коктейль из kafka в kubernetes (локально в minikube) через Helm согласно этой инструкции https://github.com/kubernetes/charts/tree/master/incubator/kafka Версия без external access работает вполне успешно Но как только меняю в values.yaml в разделе exposed на enabled: true и стартую (в новом неймспейсе этот chart) то начинается веселье. под с кафкой уходит в Init:CrashLoopBackOff Понимаю что кейс довольно специфический, но вдруг кто-то сталкивался

вопрос такой: пробую сварить коктейль из kafka в kubernetes (локально в minikube) через Helm согласно этой инструкции https://github.com/kubernetes/charts/tree/master/incubator/kafka Версия без external access работает вполне успешно Но как только меняю в values.yaml в разделе exposed на enabled: true и стартую (в новом неймспейсе этот chart) то начинается веселье. под с кафкой уходит в Init:CrashLoopBackOff Понимаю что кейс довольно специфический, но вдруг кто-то сталкивался

1) The external access feature of this chart was tested with kops on AWS using flannel networking. 2) If you wish to enable external access to Kafka running in kops, your security groups will likely need to be adjusted to allow non-Kubernetes nodes (e.g. bastion) to access the Kafka external listener port range. Я так понимаю у вас не авс? А секгрупу сделали в кубере?

вопрос такой: пробую сварить коктейль из kafka в kubernetes (локально в minikube) через Helm согласно этой инструкции https://github.com/kubernetes/charts/tree/master/incubator/kafka Версия без external access работает вполне успешно Но как только меняю в values.yaml в разделе exposed на enabled: true и стартую (в новом неймспейсе этот chart) то начинается веселье. под с кафкой уходит в Init:CrashLoopBackOff Понимаю что кейс довольно специфический, но вдруг кто-то сталкивался

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

1) The external access feature of this chart was tested with kops on AWS using flannel networking. 2) If you wish to enable external access to Kafka running in kops, your security groups will likely need to be adjusted to allow non-Kubernetes nodes (e.g. bastion) to access the Kafka external listener port range. Я так понимаю у вас не авс? А секгрупу сделали в кубере?

да совершенно верно. не AWS - сначала хотел оттестить все на локалхосте с миникубом (а потом уже на Google Cloud, AWS нет у нас). секгруппу не создавал

да совершенно верно. не AWS - сначала хотел оттестить все на локалхосте с миникубом (а потом уже на Google Cloud, AWS нет у нас). секгруппу не создавал

На авс попробуйте на мелких машинах и группа нужна. Когда заведётся попробуете без kob

Всем привет. Вопрос про rollback deployment'ов: скажем у меня в deployment'е постоянно указан образ app:latest и для обновления сервиса мне нужно по сути просто спулить новый образ. Если я хочу откатиться, то откуда кубер возьмёт предыдущий образ, если он точно такой же app:latest? Или принято прямо по версиям выкатывать? Плюс в самом deployment'е стоит imagePullPolicy: Always. Насколько принято так делать и в чём минус Always тут в вышеописанном сценарии? Спасибо.

Всем привет. Вопрос про rollback deployment'ов: скажем у меня в deployment'е постоянно указан образ app:latest и для обновления сервиса мне нужно по сути просто спулить новый образ. Если я хочу откатиться, то откуда кубер возьмёт предыдущий образ, если он точно такой же app:latest? Или принято прямо по версиям выкатывать? Плюс в самом deployment'е стоит imagePullPolicy: Always. Насколько принято так делать и в чём минус Always тут в вышеописанном сценарии? Спасибо.

У меня в кубере-через-ранчер latest не цепляется. Указываю принудительно версию

Всем привет. Вопрос про rollback deployment'ов: скажем у меня в deployment'е постоянно указан образ app:latest и для обновления сервиса мне нужно по сути просто спулить новый образ. Если я хочу откатиться, то откуда кубер возьмёт предыдущий образ, если он точно такой же app:latest? Или принято прямо по версиям выкатывать? Плюс в самом deployment'е стоит imagePullPolicy: Always. Насколько принято так делать и в чём минус Always тут в вышеописанном сценарии? Спасибо.

Но ответ мне тоже интересен)

У меня в кубере-через-ранчер latest не цепляется. Указываю принудительно версию

И что каждый раз прописываете версию вручную или как-то заавтоматизировали?

И что каждый раз прописываете версию вручную или как-то заавтоматизировали?

Вручную, пока так удобнее, но думаю над вариантами.

Ещё вопрос по ingess'ам: есть ли возможность выставлять наружу сервис через clusterip, а не nodeport в стандартном ingress'е на GKE? Перехожу с Rancher/Cattle и там аналогичная возможность есть, т.е. микросервисы открывают только свои порты в их локальную 10.42.0.0/16 сеть и далее ingress Rancher'а выставляет их наружу, не открывая и не занимая никаких дополнительных портов на хосте/ноде. При этом на load balancer'е cloud provider'а (AWS) указаны только 80 и 443 порты.

Вручную, пока так удобнее, но думаю над вариантами.

Адище какой. У меня пока сделано так: на dev окружение автоматом выкатывается образ dev:latest, который собирается из master ветки. Далее в нужный момент я отрезаю release/* ветку и из неё автоматом собирается release:latest, который автоматом выкатывается на staging. Далее есть ручной таск, который берёт образ release:latest, перетэгивает его на prod:latest и это вручную деплоится в prod. Таким образом prod защищён от автодеплоя release:latest :)

Адище какой. У меня пока сделано так: на dev окружение автоматом выкатывается образ dev:latest, который собирается из master ветки. Далее в нужный момент я отрезаю release/* ветку и из неё автоматом собирается release:latest, который автоматом выкатывается на staging. Далее есть ручной таск, который берёт образ release:latest, перетэгивает его на prod:latest и это вручную деплоится в prod. Таким образом prod защищён от автодеплоя release:latest :)

Ммм

Похоже на адище)

Когда готовы апгрейд делать, открываю в гуе и ставлю новую версию и начинается ролаут, по инстанс

Всем привет. Вопрос про rollback deployment'ов: скажем у меня в deployment'е постоянно указан образ app:latest и для обновления сервиса мне нужно по сути просто спулить новый образ. Если я хочу откатиться, то откуда кубер возьмёт предыдущий образ, если он точно такой же app:latest? Или принято прямо по версиям выкатывать? Плюс в самом deployment'е стоит imagePullPolicy: Always. Насколько принято так делать и в чём минус Always тут в вышеописанном сценарии? Спасибо.

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

простая практика - оперется на систему контроля версий. на tag, на commit hash, что там удобнее

простая практика - оперется на систему контроля версий. на tag, на commit hash, что там удобнее

+

простая практика - оперется на систему контроля версий. на tag, на commit hash, что там удобнее

Ага)

Ещё вопрос по ingess'ам: есть ли возможность выставлять наружу сервис через clusterip, а не nodeport в стандартном ingress'е на GKE? Перехожу с Rancher/Cattle и там аналогичная возможность есть, т.е. микросервисы открывают только свои порты в их локальную 10.42.0.0/16 сеть и далее ingress Rancher'а выставляет их наружу, не открывая и не занимая никаких дополнительных портов на хосте/ноде. При этом на load balancer'е cloud provider'а (AWS) указаны только 80 и 443 порты.

Я не смог отказаться от nodeport. В роли балансера - GCLB, он внешний по отношению к кластеру

Но я сделал в кластере свой локальный балансер, и GCLB смотрит только на его нодепорт.

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

Очевидно, но не совсем. У меня и версия контейнера создается (от номера билда) и хэш. Но в том же Rancher на Cattle после deploy, остаётся висеть убитый контейнер предыдущей версии (с тем же тэгом latest). Если есть необходимость откатиться, то вместо finish upgrade делается rollback, который убивает текущий свежий контейнер и запускает остановленный предыдущий, не перекачивая его из реестра.

ERROR: S client not available

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

Самое сложное было в выявлении и автоматизации таргетирования на нодепулы

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

Это понятно (хотя можно и без именования это сделать), но на ноде порты открываются, мне это не очень нравится. Хотя эти порты и локальные, но всё же на шаг назад по безопасности как-то получается :(

Очевидно, но не совсем. У меня и версия контейнера создается (от номера билда) и хэш. Но в том же Rancher на Cattle после deploy, остаётся висеть убитый контейнер предыдущей версии (с тем же тэгом latest). Если есть необходимость откатиться, то вместо finish upgrade делается rollback, который убивает текущий свежий контейнер и запускает остановленный предыдущий, не перекачивая его из реестра.

это уже какие то костыли снаружи. на k8s так не выйдет откатится. может быть если probe для пода скажет что он не здоров и прежний репликасет (в случае деплоймента) еще был жив целиком. но я бы на такое не надеялся

А в чем небезопасность порта? В том, что голый сервис? Я вот нжинксом внутри кластера прикрыл и балансер на него приземлял. Это позволило избежать проблемы асинхронного лага между окончанием реконфигурации GCLB и реальным эффектом от изменений. Правлю только внутрикластерный балансер часто.

это уже какие то костыли снаружи. на k8s так не выйдет откатится. может быть если probe для пода скажет что он не здоров и прежний репликасет (в случае деплоймента) еще был жив целиком. но я бы на такое не надеялся

Это штатные средства rancher-compose Rancher (1.6.x на Cattle). https://rancher.com/docs/rancher/v1.6/en/cattle/rancher-compose/commands/

--confirm-upgrade, -c Confirm that the upgrade was success and delete old containers

--rollback, -r Rollback to the previous deployed version

А в чем небезопасность порта? В том, что голый сервис? Я вот нжинксом внутри кластера прикрыл и балансер на него приземлял. Это позволило избежать проблемы асинхронного лага между окончанием реконфигурации GCLB и реальным эффектом от изменений. Правлю только внутрикластерный балансер часто.

Небезопасность, на мой взгляд, в том, что открываешь дополнительные порты на ноде. Так то они в локальной сетке и на них только load balancer смотрит, но тем не менее, на мой взгляд, несколько странно, что K8s не позволяет делать так же, как и старый Rancher на Cattle + ещё плюшки. Получается минус возможности какие-то :(

Реализация открытости нодепортов в GKE устроена следующим образом. Там сеть Calico, ставится iptables правило которое заруливает это на нужный под.

Связность порта и пода полностью автоматически на плечах кубера

Я тестировал, работает без осечек.

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

# Например есть вот такой deployment nginx'а: apiVersion: apps/v1 kind: Deployment metadata: name: nginx-app labels: app: nginx-app spec: replicas: 2 selector: matchLabels: app: nginx-app template: metadata: labels: app: nginx-app spec: nodeSelector: app: '1' containers: - image: nginx:latest name: nginx-app env: - name: test value: '1' ports: - containerPort: 80 name: nginx-http imagePullSecrets: - name: regcred --- apiVersion: v1 kind: Service metadata: name: nginx-app spec: type: NodePort ports: - port: 80 targetPort: 80 protocol: TCP name: nginx-http selector: app: nginx-app # И вот такой ingress: apiVersion: v1 data: tls.crt: "..." tls.key: "..." kind: Secret metadata: name: sslcerts namespace: default type: Opaque --- apiVersion: extensions/v1beta1 kind: Ingress metadata: name: dev-ingress annotations: kubernetes.io/ingress.global-static-ip-name: 'dev-ingress-ip' spec: tls: - secretName: sslcerts backend: serviceName: 'nginx-app' servicePort: 80

Хотя можно было сделать servicePort: nginx-http , но не обязательно.

Я TLS на GCLB вынес

--- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-ci-lb spec: replicas: 2 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1 selector: matchLabels: app: nginx-ci-lb template: metadata: labels: cijobid: job-%%CI_JOB_ID%% app: nginx-ci-lb network-publicweb: publicweb network-loadbalancer: loadbalancer spec: containers: - name: nginx-ci-lb image: %%IMAGE_NGINXCILB%% imagePullPolicy: Always ports: - containerPort: 80 Выставление портов: --- kind: Service apiVersion: v1 metadata: name: nginx-ci-lb namespace: default labels: app: nginx-ci-lb spec: ports: - name: http protocol: TCP port: 80 targetPort: 80 #- name: https # protocol: TCP # port: 443 # targetPort: 443 selector: app: nginx-ci-lb # uncomment if you need auto-GLB #type: LoadBalancer #externalTrafficPolicy: Local # if you don't want to expose Nginx to the public network via an autoconfigured GCLB, you shoud use the setup below: type: NodePort sessionAffinity: None --- # used only on nginx to allow ANY (including public) incoming requests! # apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: network-publicweb spec: podSelector: matchLabels: network-publicweb: publicweb policyTypes: - Ingress ingress: - from: [] ports: - protocol: TCP port: 80 - protocol: TCP port: 443

Это как сделал я у себя

Этот внутрикластерный балансер в который идет GCLB

Ну так оно же и есть на GCLB тут. Когда его определяешь в ingress'е, то он и создаёт LB же.

# uncomment if you need auto-GLB #type: LoadBalancer #externalTrafficPolicy: Local

Это если ты не хочешь сам менеджить GCLB

Оно тогда все само зааллоцирует и отконфигурит

Но если вдруг переделать понадобится, то придется серьезно разобраться в четырехслойной модели GCLB

Иначе оно при каждом переделывании будет порождать зажор ресов в GCLB и ты упрешься в квоты проекта

Мы это прошли и отказались от этой автофичи

Слишком много потом руками чистить приходится

В панели GCP

Оно мне недавно регнулось на квоту бэкэндов, я просто сделал запрос на увеличение до 30 и получил автоаппрув в течении 5 минут...

Это понятно, но это плохой признак