поставь /*

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

так чекни хедер и проверку на терминирование ссл

раззным ингрессам нужен разный подход

Подскажите по тупому вопросу. В спеке пода можно чтоб было одновременно и env и envFrom? или одно перезатрет другое?

можно

Подскажите по тупому вопросу. В спеке пода можно чтоб было одновременно и env и envFrom? или одно перезатрет другое?

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#container-v1-core смотри описание поля envFrom

привет Подскажите, почему kubectl delete pods —all —namespace=123 пишет, что удалила поды, но на самом деле нет. флаг —now ничего не изменил флаг —force=true тоже поменял —now на —grace-period=0 поды стали sheduling но не удалились

Потому что там стейтфулсет или деплоймент развёрнут и он заново их запускает?

хм действительно а как убить деплоймент?

kubectl delete deployment?

delete deployment

спс

kubectl delete deployment?

еще можно kubectl scale —replicas=0 сделать, если сам деплоймент удалять не хочется

Подскажите, как посмотреть список всех апи в кубере с версиями?

Подскажите, как посмотреть список всех апи в кубере с версиями?

kubectl api-versions

Коллеги, сталкиваюсь со странным поведением при сборе метрик: периодически пропадают метрики от одной ноды, забираемые промом по /api/v1/nodes/node08/proxy/metrics/cadvisor. При этом по /api/v1/nodes/node08/proxy/metrics все отдается стабильно(график метрики up на скрине). kubelet v1.11.1, docker://18.6.2, другие аналогичные ноды, расположенные рядом, такой проблемой на страдают. Подскажите, в какую сторону смотреть?

Подскажите

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

Если у меня есть test1 / test2 неймспесы И в двух есть деплоймент и сервис dep Я могу обращаться как dep.test2 так и dep.test1 Но просто dep я смогу обратиться только из неймспейса в котором он находится?

Ну да

Ну да

Супер, спасибо

Коллеги, приветствую! Всю голову уже сломал. Может быть у вас будут светлые мысли. Имею: * Deployment реплицированный Х раз с http портом 80 и tcp портом 50050 * Сервис * Запросы из вне пробрасываются через ingress Задача: каждый клиент, отправляющий запросы на 80 и 50050 порты направлялись на общий backend (либо оба запроса на backend 1 либо на backend 2) Пробовал в сервисе прописать sessionAffinity: ClientIP, но результата это не дало: запросы хаотично роутятся (то 80 порт на backend 1 и 50050 на backend2 и т.д.)

Схема: https://ibb.co/0nzrJfG

tcp через ingress проикнул согласно документации: https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/

ты уже хочешь неправильного

Ого, даже смену протокола от ингресса уже хотят?

смену протокола?

ты уже хочешь неправильного

внутри деплоймента два пода, которые хранят и обрабатывают данные пока есть клиент. Тако вот небольшой stateful получается. Избавится от хранения состояния можно только путем вынесения во внешнюю субд этих данных, но т.к. ttl этих данных слишком мал, не хотелось бы городить огород из внешнего хранилища

внутри деплоймента два пода, которые хранят и обрабатывают данные пока есть клиент. Тако вот небольшой stateful получается. Избавится от хранения состояния можно только путем вынесения во внешнюю субд этих данных, но т.к. ttl этих данных слишком мал, не хотелось бы городить огород из внешнего хранилища

складывайте сессии/данные в общий redis/memcache, и будет вам счастье из коробки

смену протокола?

Один порт http, второй tcp. Как ему балансировать http запрос по портам?

внутри деплоймента два пода, которые хранят и обрабатывают данные пока есть клиент. Тако вот небольшой stateful получается. Избавится от хранения состояния можно только путем вынесения во внешнюю субд этих данных, но т.к. ttl этих данных слишком мал, не хотелось бы городить огород из внешнего хранилища

stateful в кубере это плохо

Один порт http, второй tcp. Как ему балансировать http запрос по портам?

как вариант по Client IP, как это реализовано в сервисах

как вариант по Client IP, как это реализовано в сервисах

То есть, превращать все в http?

но ingress умеет только по cookie банасировать, что делает его непригодным для tcp

Stateful set я задеплоил Файлики посохронял Нода сдохла, визор умер Начальник вы**ал в ан*л

пхах

щикарно

То есть, превращать все в http?

зачем ему все в http превращать? Ingress в частном случае это nginx. Nginx умеет балансировать не только 7 уровня протоколы, но и 4, так же по client ip

Подскажите куда копать, ingress с ssl беком apache без ssl, не грузит картинки, контент Как только на ингресе ssl вырубаю все ок в логах все чисто, хз уже что думать

текс, нашел проблему ` Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure script '<URL>'. This request has been blocked; the content must be served over HTTPS. `

либо хедеры секьюрные отрубать, либо код фиксить что бы по https грузились ресурсы

Оно? > if ($scheme = https) { > more_set_headers "Strict-Transport-Security: max-age=15724800; includeSubDomains";

чем грозит их отрубание?

в шаблонах, css и js не надо указывать схемы в урлах

Какие хедеры, mixed content браузером блокируется.

чем грозит их отрубание?

ничем вот только у всех оно уже закэшировалось, кто зашел на сайт :D

отключение HSTS не поможет с mixed content

да пока что это дев окружение

чем грозит их отрубание?

отключишь hsts - браузеры перестануть людей прибивать к https соединению. Лучше код фиксить

спасибо

скажите, есть какой нить способ узнать внутренний ип контейнера?

kubectl get pods -o wide

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

kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES memcached-0 2/2 Running 5 9h 10.0.1.234 vpc-stage-k8s-node <none> <none> rabbitmq-0 1/1 Running 2 9h 10.0.1.232 vpc-stage-k8s-node <none> <none> sphinx-5dc856d4d9-mllfx 1/1 Running 3 9h 10.0.1.236 vpc-stage-k8s-node <none> <none> tiller-deploy-bd6dc9fbc-fdwcm 1/1 Running 8 31h 10.0.1.237 vpc-stage-k8s-node <none> <none>

показывает же

что за сообщение от кубелета? reflector.go:270] object-"NAMESPACE"/"migrate-parameters": watch of *v1.ConfigMap ended with: too old resource version: 42323883 (42325514)

все работает при этом. но в логи постоянно пишется

# cat /var/log/syslog| grep "too old resource version" | grep "Jun 25"| wc -l 1005

за сегодня 1000 таких записей

и это только на одной ноде. на других также

Вообще, само по себе это нормально и ошибкой не является

Однако записей многовато, тут спору нет, но про root cause можно только гадать

Я бы в любом случае копал в сторону аписервера

ок. спс. попробую потыкать аписервер

кто использует prometheus-operator? подскажите, можно ли использовать alertmanager, который не в кубере?

кто использует prometheus-operator? подскажите, можно ли использовать alertmanager, который не в кубере?

Можно

а где хранятся эти настройки? я прогрепал на поиск конфига и нчиего не нашел

а где хранятся эти настройки? я прогрепал на поиск конфига и нчиего не нашел

https://github.com/helm/charts/blob/master/stable/prometheus-operator/values.yaml ?

Всем привет! Столкнулся с багом при создании сервиса с типом лоад балансер и типом трафика локал. NodeHealthCheck возвращает 503 - мол нет локальных подов. Но у меня однонодовая конфигурация (aws) так что под есть и он естественно на этой же ноде. В сервисе в эндпоинтах под есть.

Всем привет! Столкнулся с багом при создании сервиса с типом лоад балансер и типом трафика локал. NodeHealthCheck возвращает 503 - мол нет локальных подов. Но у меня однонодовая конфигурация (aws) так что под есть и он естественно на этой же ноде. В сервисе в эндпоинтах под есть.

Я тоже сталкивался. Там вроде нюанс в опциях к kube-proxy, ща вспомню

Короче, то ли --bind-address, то ли вроде того. У меня было связано с тем, что адрес заведомо не соответствовал ни одному сетевому интерфейсу на ноде

Короче, то ли --bind-address, то ли вроде того. У меня было связано с тем, что адрес заведомо не соответствовал ни одному сетевому интерфейсу на ноде

Спасибо !!!

Что за атака клонов ?

ссылочку в чат вебинарчика кинули

Посоны, если kubeadm alpha certs renew all сделать или на старых версиях где этого нет каждый сертификат в отдельности генерить kubeadm alpha phase certs apiserver-kubelet-client итд итп, так вот вопрос: это на каждом мастере нужно делать или сертификаты можно руками по мастерам растащить-растиражировать?

Посоны, если kubeadm alpha certs renew all сделать или на старых версиях где этого нет каждый сертификат в отдельности генерить kubeadm alpha phase certs apiserver-kubelet-client итд итп, так вот вопрос: это на каждом мастере нужно делать или сертификаты можно руками по мастерам растащить-растиражировать?

второе

Берешь серт с масетра

и по сервам раскидываешь

Работать будет