V
ну да вот в старой доке было, 19.03.04 ставить или последний лучше 19.03.13
Size: a a a
2020 November 09
СЛ
Слушайте ребята такой как лучше организовать доступ к кластеру вот например я хочу что бы у меня были разрабы у них свой доступ они там могут делать то-то то-то, + когда они что-то делают например в дашборде с исмпользованием своего токена я это мог посмотреть ?
GG
Сергей Ладутько
Слушайте ребята такой как лучше организовать доступ к кластеру вот например я хочу что бы у меня были разрабы у них свой доступ они там могут делать то-то то-то, + когда они что-то делают например в дашборде с исмпользованием своего токена я это мог посмотреть ?
просто включай аудит
СЛ
просто включай аудит
это как ?
I
Всем привет! А почему серт-менеджер (версия 1,0,1) может не выдавать сертификаты?
В логах у него:
Также:
Аннотации у ингресса стоят вот такие:
Такой cluster-issuer присутствует:
В логах у него:
Operation cannot be fulfilled on certificaterequests.cert-manager.io \"my.example.com-crt-ts72t\": the object has been modified; please apply your changes to the latest version and try again
Также:
$ kubectl get certificate my.example.com-crt -o yaml
...
status:
conditions:
- lastTransitionTime: "2020-11-09T09:26:41Z"
message: Issuing certificate as Secret does not exist
reason: DoesNotExist
status: "False"
type: Ready
- lastTransitionTime: "2020-11-09T09:26:41Z"
message: Issuing certificate as Secret does not exist
reason: DoesNotExist
status: "True"
type: Issuing
Аннотации у ингресса стоят вот такие:
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
certmanager.k8s.io/cluster-issuer: letsencrypt-prod
kubernetes.io/tls-acme: '"true"'
Такой cluster-issuer присутствует:
$ kubectl get clusterissuers
NAME READY AGE
letsencrypt-prod True 57d
S
подскажите, можно ли в папке /etc/kubernetes/manifests/ определять не только поды , но и роли и ролебиндинги?
Е
это же директория для статик-подов, другие ресурсы в ней kubelet вряд ли заметит
D
Вообще келетет любой .yaml файл должен сожрать. Надо пробовать )
GG
подскажите, можно ли в папке /etc/kubernetes/manifests/ определять не только поды , но и роли и ролебиндинги?
плохая идея
S
плохая идея
чем плохо?
AK
чем плохо?
Тем, что он жуёт объекты с
kind: Pod оттуда только.
S
Тем, что он жуёт объекты с
kind: Pod оттуда только.ох. ясно
ЕП
Всем шалом. Как новичёк в k8s пытаюсь найти способ использовать https для внутренних сервисов без попаболи, соответственно хочется "трастовый" сертификат чтобы был у, например, elasticsearch (который поставил как ECK) для работы своих микросервисов с ним.
Нашёл как способ эту фичу https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/
Но она только для 1.19, а у меня 1.18
Какие ещё способы есть оптимальные добится ssl внутри кластера?
Нашёл как способ эту фичу https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/
Но она только для 1.19, а у меня 1.18
Какие ещё способы есть оптимальные добится ssl внутри кластера?
V
Коллеги, приветствую
помогите разобраться с rewrite в ingress
для api есть легаси урл /api/srv/status (он должен работать для старых сервисов)
нужно что бы новые сервисы стучали по новому урлу /api/status/productN
также должны быть доступны следующие пути / , /api/srv
правильно ли я конфигурирю ингресс?
помогите разобраться с rewrite в ingress
для api есть легаси урл /api/srv/status (он должен работать для старых сервисов)
нужно что бы новые сервисы стучали по новому урлу /api/status/productN
также должны быть доступны следующие пути / , /api/srv
правильно ли я конфигурирю ингресс?
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$1$2$3
spec:
rules:
- host: dev-host
http:
paths:
- path: /
- path: /(api)(/srv)
- path: /(api)/srv(/status)(/product1)
- path: /(api)/srv(/status)(/product2)
- path: /(api)/(srv)(/status)S
Коллеги, приветствую
помогите разобраться с rewrite в ingress
для api есть легаси урл /api/srv/status (он должен работать для старых сервисов)
нужно что бы новые сервисы стучали по новому урлу /api/status/productN
также должны быть доступны следующие пути / , /api/srv
правильно ли я конфигурирю ингресс?
помогите разобраться с rewrite в ingress
для api есть легаси урл /api/srv/status (он должен работать для старых сервисов)
нужно что бы новые сервисы стучали по новому урлу /api/status/productN
также должны быть доступны следующие пути / , /api/srv
правильно ли я конфигурирю ингресс?
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$1$2$3
spec:
rules:
- host: dev-host
http:
paths:
- path: /
- path: /(api)(/srv)
- path: /(api)/srv(/status)(/product1)
- path: /(api)/srv(/status)(/product2)
- path: /(api)/(srv)(/status)если есть - path: / , то все остальное не нужно
S
если есть - path: / , то все остальное не нужно
либо там разные бекенды должны быть
I
Всем привет! А почему серт-менеджер (версия 1,0,1) может не выдавать сертификаты?
В логах у него:
Также:
Аннотации у ингресса стоят вот такие:
Такой cluster-issuer присутствует:
В логах у него:
Operation cannot be fulfilled on certificaterequests.cert-manager.io \"my.example.com-crt-ts72t\": the object has been modified; please apply your changes to the latest version and try again
Также:
$ kubectl get certificate my.example.com-crt -o yaml
...
status:
conditions:
- lastTransitionTime: "2020-11-09T09:26:41Z"
message: Issuing certificate as Secret does not exist
reason: DoesNotExist
status: "False"
type: Ready
- lastTransitionTime: "2020-11-09T09:26:41Z"
message: Issuing certificate as Secret does not exist
reason: DoesNotExist
status: "True"
type: Issuing
Аннотации у ингресса стоят вот такие:
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
certmanager.k8s.io/cluster-issuer: letsencrypt-prod
kubernetes.io/tls-acme: '"true"'
Такой cluster-issuer присутствует:
$ kubectl get clusterissuers
NAME READY AGE
letsencrypt-prod True 57d
Выяснил, что было не так. Оказывается, серт-менеджер уперся в рейт-лимиты летсэнкрипта и потому не мог выпустить ни один новый сертификат. У серт-менеджера есть какие-нибудь настройки, чтобы "размазывать" получение сертификатов по времени? Чтобы не за один присест он получал всё, что мог, потом падал по рейтлимитам, потом снова пытался получить оставшееся
A
Всем шалом. Как новичёк в k8s пытаюсь найти способ использовать https для внутренних сервисов без попаболи, соответственно хочется "трастовый" сертификат чтобы был у, например, elasticsearch (который поставил как ECK) для работы своих микросервисов с ним.
Нашёл как способ эту фичу https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/
Но она только для 1.19, а у меня 1.18
Какие ещё способы есть оптимальные добится ssl внутри кластера?
Нашёл как способ эту фичу https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/
Но она только для 1.19, а у меня 1.18
Какие ещё способы есть оптимальные добится ssl внутри кластера?
Подписывай сам CA кубера