а тут спецов по openshift не появилось?

А как шедулеры будут реализованы? Они распределенные? Там есть какие-то гарантии?

“A scheduled job creates a job object about once per execution time of its schedule. We say “about” because there are certain circumstances where two jobs might be created, or no job might be created. We attempt to make these rare, but do not completely prevent them. Therefore, jobs should be idempotent.” Я правильно понимаю, что “оно может сработать, может не сработать, может сработать два раза. Вы уже не обесудьте” ?

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

или "да, мы понимаем что все должно быть красиво... в следующих релизах поправим"

ну вот AWS Lambda говорят, что сработает как минимум один раз. То есть может быть и два, но чтобы не сработало быть не может. То есть, если идемпотентная функция, то должно быть норм. С кубернетесом я так понял идемпотентность не поможет, ибо может вообще не выполниться.

в общем жду на гугле когда обновится, потестю

ну вот AWS Lambda говорят, что сработает как минимум один раз. То есть может быть и два, но чтобы не сработало быть не может. То есть, если идемпотентная функция, то должно быть норм. С кубернетесом я так понял идемпотентность не поможет, ибо может вообще не выполниться.

Это проблема вообще всех похожих систем. Нету очереди такой, что бы гарантировала именно ОДНУ доставку сообщения, а не КАК МИНИМУМ ОДНУ

Ну я понимаю. Но хотя бы одну кубернетес гарантирует или нет? Вот в чём вопрос.

а pod можно развернуть в режиме global?

или это как раз нужно делать через Димона :))

rnmv@rnmv-i5:~$ kubectl get svc NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes 100.64.0.1 <none> 443/TCP 3h nginx 100.64.7.221 <pending> 80/TCP 7m уже почти 3 минуты на pending... После выполнения kubectl expose deployment nginx --port 80 --type LoadBalancer. Что может быть не так?

Кластер вроде успешно запустился

А как шедулеры будут реализованы? Они распределенные? Там есть какие-то гарантии?

я даже не заглядывал в спеку, но kubernetes держит один активный мастер и хранит все в etcd, тут по-моему особых вариантов-то нет.

Всем привет! Ребят, хочу совета спросить у тех, кто использует deis workflow. Как вы считаете лучше "поделить" апп на тест, стейдж и прод окружения?

Всем привет! Ребят, хочу совета спросить у тех, кто использует deis workflow. Как вы считаете лучше "поделить" апп на тест, стейдж и прод окружения?

лучше просто не использовать deis

кстати, официальный репозиторий с helm начали заполнять: https://github.com/kubernetes/charts

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

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

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

Он очень ограниченный. Но если тебе нужно задеплоить вордпрес, то наверное пойдет. В других случаях нужно использовать kubernetes

окай =) я учту, что ничего сложного лучше через deis не заливать. Вопрос-то в другом, есть те, кто использует и как разбивают на test/stage/prod =)

ну для начала прод и стейдж/тест держать в одном кластере как-то опасно

уф, спецы, подскажите, есть openshift пытаюсь скрестить его с jenkins прописал апи, ключ, проект, пытаюсь создать деплоймент конфиг через дженкинс, а оно мне в ответ в логах resourceVersion may not be set on objects to be created

согласен.. Если разбить на 3 отдельных кластера, то должно быть не плохо.. И деис повесить только на тестовые окружения... Хмм.

ну достаточно двух: тест+ стейдж и прод отдельно

ну в принципе да.. если апп в докер засунуть, то и тестровать его можно локалько!

ну а развернуть тестовое окружение(копию прода), можно и терраформом

никто не сталкивался с такой ошибкой? [root@srv-333770 ~]# kubectl version Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.7", GitCommit:"a2cba278cba1f6881bb0a7704d9cac6fca6ed435", GitTreeState:"clean", BuildDate:"2016-09-12T23:15:30Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} error: failed to negotiate an api version; server supports: map[], client supports: map[federation/v1beta1:{} autoscaling/v1:{} extensions/v1beta1:{} policy/v1alpha1:{} batch/v1:{} batch/v2alpha1:{} authentication.k8s.io/v1beta1:{} v1:{} authorization.k8s.io/v1beta1:{} componentconfig/v1alpha1:{} apps/v1alpha1:{} rbac.authorization.k8s.io/v1alpha1:{}]

неактуально:)

нашел решение -> расскажи сообществу

это касается видимо только google cloud

перед get-credentials надо задавать переменную окружения

[root@blabla]# export GOOGLE_APPLICATION_CREDENTIALS="path-to-key-json" [root@blabla]# gcloud container clusters get-credentials cluster-name --zone zone-name

Всем добра в этом чате) #whois ▫️Какой у вас проект или где работаете? Израильский стартап по очистке ecommerce трафика ▫️В чём вы специалист? DevOps, sysop, etc. 10+ лет опыта ▫️Чем можете быть интересны или полезны сообществу? Делиться опытом использования k8s ▫️Чем интересно сообщество вам? Инетресен опыт использования k8s на высоких нагрузках ▫️Откуда вы? Израиль ▫️Как узнали про группу? гугл: telegram kubernetes

чат, а у кого в логах контроллера видно такие ошибки E0928 09:38:44.970618 1 deployment_controller.go:400] Error syncing deployment static-namespace/static: Operation cannot be fulfilled on deployments.extensions "static": the object has been modified; please apply your changes to the latest version and try again ?

заметил, что у меня kubectl apply не каждый раз выкатывает версию

немного оффтоп, но кто-нибудь настраивал ingress парсер в fluentd для Kibana?

@exename c ошибкой не сталкивался, но выкатываю версию не через apply, а через rolling-update $K8S_RC_NAME --image=$PROJECT_IMAGE --namespace=production --image-pull-policy=IfNotPresent --update-period=0s

ну это для rc

как правильно увеличить client_max_body_size для nginx

cat nginx_extra_conf.yaml apiVersion: v1 metadata: name: nginx-ingress-controller data: body-size: "4G" kind: ConfigMap

$ cat ingress_daemonset.yaml | grep -C1 nginx-ingress-controller args: - /nginx-ingress-controller - --default-backend-service=$(POD_NAMESPACE)/default-http-backend - --nginx-configmap=$(POD_NAMESPACE)/nginx-ingress-controller

@kay_rus а ты случайно не настроил ингресс так, чтобы он видел реальные айпи клиентов?

хм. а он у меня их види по дефолту

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

или как ты запускаешь поды?

какой ингресс используешь*

nginx controller, можно твой манифест посмотреть?

у меня вот gcr.io/google_containers/nginx-ingress-controller:0.8.3

ну и я его юзал

покажи логи

я его сейчас опустил

У меня вот так логи выглядят: 76.72.167.90 - [76.72.167.90] - - [28/Sep/2016:14:41:01 +0000] "GET / HTTP/1.1" 200 4199 "-" "Pingdom.com_bot_version_1.4_(http://www.pingdom.com/)" 168 0.004 10.64.62.3:8000 14770 0.004 200

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

а на чем ты поднял кубер?

голое железо

ось какая?

ubuntu

ставилось ансамблем

а манифест для контроллера ты брал стандартный из доки?

да

daemonset

который слушает hostPost 80/443

т.е. nginx видит реальные запросы

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

я поднял через rc

ясно

я очень удивлен тем, что community совершенно плевать на логи в kubernetes.

и прочий ELK stack

информации практически ноль, конфиги устаревшие, и прочие радости

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

“правильно” у всех разное

да банальный nginx

ingress

изкоробки решение вообще не работает

логи не парсятся

плагин fluentd для kubenretes вообще не используется

ELK построен на устаревших replication controller'ах

как обновить конфиги с nginx