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

Там в 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 минут...

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

Ты по сути не контролируешь порожденные сущности

Мне надо ещё покурить маны, в-общем :) Пока что у меня вот такое определение ingress, при создании которого оно автоматом создаёт всё, что нужно на GCLB и направляет на нужные порты на нодах

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 rules: - host: biz.dev.example.com http: paths: - path: /gw/xyz/api backend: serviceName: 'gateway-xyz' servicePort: 80 - path: /gw/uyt/api backend: serviceName: 'gateway-uyt' servicePort: 80 - path: /api/v4 backend: serviceName: 'payment-api' servicePort: 80 - path: /demo backend: serviceName: 'demo-app' servicePort: 80 - path: /gua backend: serviceName: 'gua-app' servicePort: 80 - path: backend: serviceName: 'biz-app' servicePort: 80 - host: core.dev.example.com http: paths: - path: /set/api backend: serviceName: 'set-app' servicePort: 80 - path: /set backend: serviceName: 'set-app' servicePort: 80 - backend: serviceName: 'core-app' servicePort: 80 - host: wallet.dev.example.com http: paths: - path: /gw/xyz/web backend: serviceName: 'gateway-xyz' servicePort: 80 - path: /gw/uyt/web backend: serviceName: 'gateway-uyt' servicePort: 80 - path: backend: serviceName: 'wallet-app' servicePort: 80 - host: dev.example.com http: paths: - backend: serviceName: 'www-app' servicePort: 80 - host: www.dev.example.com http: paths: - backend: serviceName: 'www-app' servicePort: 80 - host: ep.dev.example.com http: paths: - path: /api/v1 backend: serviceName: 'mn-adapter-app' servicePort: 80

Вот такой ингресс я не использовал

У меня вместо ингресса nginx, который я полностью контролирую в плане внутренней конфигурации + на кластере сетевые политики,

Это позволяет мне не городить большее количество посредников на пути до сервиса

сам nginx стучится на ClusterIP:порт сервисов

Господа, нубский вопрос, пробую calico в кубере, на трех VM (CentOS 7) masters. Валится на master2 & master3 , как заставить calico-node использовать eth0 интерфейс вместо бриджа докера, он на всех 3-х машинах одинаковый и соответсвенно не взлетают поды на мастере2 и мастере3??? в деплоименте написано IP : autodetect, в мурзилке calico что IP_AUTODETECTION_METHOD не используется с kebernetes api

ребят, а как то на кубере можно сделать нечто вроде pre-upgrade hook хелмовских ? Хочется перед upgrade моего деплоя делать некоторый набор действий. InitContainers не подходят, потому что они запускаются каждый раз при рестарте pod и вобще для всех pod в рамках replicaset. А мне нужно 1 раз.

Не очень хочется это на уровень ci выносить

Всем привет, пытаюсь прикрутить кастомный fluentd что бы gelf плевался, через DaemonSet. kubectl create -f fluentd-daemonset-gelf.yaml вот отсюда https://github.com/xbernpa/fluentd-kubernetes-gelf/blob/master/kubernetes/fluentd-daemonset-gelf.yaml Но его почему то нет в списках Что я делаю не так? > kubectl get ds fluentd Error from server (NotFound): daemonsets.extensions "fluentd" not found

--namespace kube-system

Всем привет, пытаюсь прикрутить кастомный fluentd что бы gelf плевался, через DaemonSet. kubectl create -f fluentd-daemonset-gelf.yaml вот отсюда https://github.com/xbernpa/fluentd-kubernetes-gelf/blob/master/kubernetes/fluentd-daemonset-gelf.yaml Но его почему то нет в списках Что я делаю не так? > kubectl get ds fluentd Error from server (NotFound): daemonsets.extensions "fluentd" not found

в твоей версии kubernetes api - daemonset уехал из apiVersion: extensions/v1beta1

просто по умолчанию выводится содержимое --namespace=default

Может кто то решал подобную задачу CI деплою через helm бандл приложения нужно что бы при старте postgresql скачивал дамп по sftp/scp и заливал к себе Есть вариант собрать свой контейнер постгреса и в entrypoint добавить это залитие, или можно как - то через хуки схитрить?

Может кто то решал подобную задачу CI деплою через helm бандл приложения нужно что бы при старте postgresql скачивал дамп по sftp/scp и заливал к себе Есть вариант собрать свой контейнер постгреса и в entrypoint добавить это залитие, или можно как - то через хуки схитрить?

initContainers

С одинаковым volume в init и основном.

initContainers

в init я могу скачать, но я не смогу залить дамп до запуска самого engine или можно делать дамп через копирование /var/lib - но это такое себе занятие

pg_basebackup прекрасно снимает дамп и разворачивает его через перемещение файлов.

в init я могу скачать, но я не смогу залить дамп до запуска самого engine или можно делать дамп через копирование /var/lib - но это такое себе занятие

#!/bin/bash set -e write_config() { cat << EOF > /mnt/postgresql.conf listen_addresses = '*' max_connections = 500 log_destination = 'stderr' EOF cat << EOF > /mnt/pg_hba.conf local all all trust host all all all trust EOF } if [ -e "/mnt/deployed" ]; then echo "Database is already deployed" write_config exit 0 fi rm -frv /mnt/* curl --limit-rate 10M "$DUMP_URL" | tar -C /mnt -xvz write_config chown -R 70:70 /mnt rm -f /mnt/recovery* /mnt/backup_label touch /mnt/deployed printf "%s\n" 'Exiting init container'

#!/bin/bash set -e write_config() { cat << EOF > /mnt/postgresql.conf listen_addresses = '*' max_connections = 500 log_destination = 'stderr' EOF cat << EOF > /mnt/pg_hba.conf local all all trust host all all all trust EOF } if [ -e "/mnt/deployed" ]; then echo "Database is already deployed" write_config exit 0 fi rm -frv /mnt/* curl --limit-rate 10M "$DUMP_URL" | tar -C /mnt -xvz write_config chown -R 70:70 /mnt rm -f /mnt/recovery* /mnt/backup_label touch /mnt/deployed printf "%s\n" 'Exiting init container'

Ого! Спасибо) Я как то и не думал в эту сторону, надо это определённо вариант

есть вопрос по калико, его как лучше на куб ставить, со своим etcd или все таки что-бы он вытаскивал данные по подсетям из куба?

ставь с CRD

https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/calico#installing-with-the-kubernetes-api-datastore50-nodes-or-less

Ребят а есть вообще веб-сервера для k8s с которыми он сможет нативно работать?

Ребят а есть вообще веб-сервера для k8s с которыми он сможет нативно работать?

В каком смысле?

В каком смысле?

типа управляться не образами а напрямую kubectl

коллега грит где то видел называется на P больше инфы нет:)

ну, в кубе все управляется с помощью kubectl

Что значит образами?

Возник вопрос по обработке соединений при апдейте сервиса. Как k8s себя ведет с активными соединеняими? Допустим есть http сервис в 2х репликах. Пошло задание на обновление. Поднялось 1 новое приложение, осталось 2 старых (на которых висят активные коннекты). Куда сейчас пойдут новые коннекты? на 1 новый экземпляр или и на старые и на новый? Что будет, если коннект не успеет отработать на старом приложении, когда k8s начнет гасить эти старые экземпляры? Оборвет его?

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

ps https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/ читал. :)

Коннекты пойдут на новый, старый должен загаситься в рамках grace time, за которое сервис должен успеть обаботать все коннекты

Коннекты пойдут на новый, старый должен загаситься в рамках grace time, за которое сервис должен успеть обаботать все коннекты

я бы хапрокси поднял

кубер вряд ли сам догадается а коннекты просто порвет

т.е. при апгрейде будет некий период времени, когда вместо 2х-3х-10 реплик одного приложения будет трудиться лишь 1?

типа того

Есть же rolling update для этого вроде

я бы сделал два сервиса новые контейнеры и старые дал бы их хапрокси поднял бы новую версию, перебросил бы на нее все, а потом убил бы старый rolling не пробовал

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

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

Есть же rolling update для этого вроде

да, вот я касательно его спрашиваю, не очень понятно из доки

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

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

да

Он обновляет не все сразу а постепенно. На сколько я знаю "постепенность" можно настроить

И по логике: перед тем как старому приложению пойдет сигнал "выключайся" k8s прекратит заворачивать на него трафик, что бы приложение спокойно дожевало уже имеющиеся запросы и погасилось?

И по логике: перед тем как старому приложению пойдет сигнал "выключайся" k8s прекратит заворачивать на него трафик, что бы приложение спокойно дожевало уже имеющиеся запросы и погасилось?

Вот на счет этого не знаю. Возможно удалит с ингресса

спасиб, буду тестить :)

Привет! Есть ли способ сделать в кубере очередь задач, где каждая новая запускается в новом докере, лучше чем job + rabbitMQ (https://kubernetes.io/docs/tasks/job/coarse-parallel-processing-work-queue/) ?

спасиб, буду тестить :)

https://ru.coursera.org/lecture/google-kubernetes-engine/deployments-and-rolling-updates-f25uw

спасибо

Ребят а есть вообще веб-сервера для k8s с которыми он сможет нативно работать?

Rancher

День добрый. Каким образом можно запустить usbip в kubernetes? В docker я запускаю контейнер, подключая через volumes /dev и /lib/modules с хостовой системы (privileged включен). В кубике когда я такое делаю, то получаю ошибку при выполнении usbip attach usbip: error: import device usbip: error: query

Всем привет, по долгу работы зарылся в AWS и небыло времени продолжить со своим on-premise кластером на k8s и опытами над ним, 2 месяца его не трогал, сегодня включил, все поднялось без задоринки, конфа такая 3 etcd + 3 master + (n+1 nodes), wawe netwok, версия k8s 1.10.1, все поднималось вручную без спрея итд. Вопрос вот в чем, 2 месяца я вообще не трогал тему кубика, что-то кординально поменялось ?, появились новые не забагованые сетевые фреймы или подчинили фланел ?

k8s новый вышел.

helm постоянно отадет User "system:serviceaccount:kube-system:default" cannot get namespaces in the namespace "default" Если делаю kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}' то helm перестает видеть tiller.

надо создать clusterrole и clusterrolebinding для этого SA с соотв. пермишшнами

No API token found for service account "default", retry after the token is automatically created and added to the service account # kubectl describe serviceaccounts default Name: default Namespace: default Labels: <none> Mountable secrets: <none> Tokens: <none> Events: <none>

встречался кто?

--service-account-private-key-file && —service-account-key-file есть

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

нужно использовать нормальный тег вместо latest