Телеграмм чат группы ru_openshift страница 1195

parrot.ru

Рейтинг популярных групп и каналов

В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

OpenShift - русскоязычное сообщество

758 membersпожаловаться на группу

2021 March 11

АС

Андрей Суковицын... in OpenShift - русскоязычное сообщество

Привет.
Подскажите пж. вот это https://access.redhat.com/solutions/2988521 актуально для 4.x ?
Есть технический sa, которому надо дать права на создание проектов и административные права внутри этих проектов.

Red Hat Customer Portal

Allow serviceaccount to create project resource on Openshift 3.x - Red Hat Customer Portal

A serviceaccount with self-provisioner access is blocked from create project. Is there any advise whether there are any existing cluster roles (other than cluster-admin e.t.c) which would allow this? If not, please advise how we'd go about creating a new cluster role for this operation. Permission denied while trying to create a project with a service account oc new-project abc Error from server: You may not request a new project via this API.

источник

13:59пожаловаться #1

И

Игорь in OpenShift - русскоязычное сообщество

а вы какой командой права выдавали self-provisioner oc adm policy add-cluster-role-to-group/user ?

источник

14:14пожаловаться #2

АС

Андрей Суковицын... in OpenShift - русскоязычное сообщество

я ещё не выдавал, но хочу

источник

14:44пожаловаться #3

АС

Андрей Суковицын... in OpenShift - русскоязычное сообщество

да oc adm policy add-cluster-role-to-user self-provisioner <sa-name>

источник

14:45пожаловаться #4

И

Игорь in OpenShift - русскоязычное сообщество

мне кажется это должно сработать `oc adm groups new test serviceaccount && oc adm policy add-cluster-role-to-group self-provisioner test`

источник

14:50пожаловаться #5

АС

Андрей Суковицын... in OpenShift - русскоязычное сообщество

мне кажется это должно сработать `oc adm groups new test serviceaccount && oc adm policy add-cluster-role-to-group self-provisioner test`

да, это сработает.
вопрос про то, что по инструкции RH этого не достаточно для того, чтобы sa мог создавать неймспейсы

источник

14:53пожаловаться #6

И

Игорь in OpenShift - русскоязычное сообщество

почему же

источник

14:54пожаловаться #7

И

Игорь in OpenShift - русскоязычное сообщество

разве там вопрос не о выдаче прав sa напрямую минуя группу?

источник

14:54пожаловаться #8

АС

Андрей Суковицын... in OpenShift - русскоязычное сообщество

Андрей Суковицын

да, это сработает.
вопрос про то, что по инструкции RH этого не достаточно для того, чтобы sa мог создавать неймспейсы

- для версии 3.5 и ниже нужно делать дополнительную роль.
Попробовал в 4.6 напрямую назначить права - сработало.

источник

15:07пожаловаться #9

АС

Андрей Суковицын... in OpenShift - русскоязычное сообщество

А вот ещё момент, при удалении роли self-provisioner у sa есть вот такой ворнинг:
Warning: Your changes may get lost whenever a master is restarted, unless you prevent reconciliation of this rolebinding using the following command: oc annotate clusterrolebinding.rbac self-provisioners 'rbac.authorization.kubernetes.io/autoupdate=false' --overwrite

источник

15:12пожаловаться #10

R

Rus in OpenShift - русскоязычное сообщество

Суток! Коллеги, а на сколько плохая идея добавлять свои метки с 'системным' namaspace, тоесть по сути openshift-*

источник

17:42пожаловаться #11

2021 March 12

S

Svetozar in OpenShift - русскоязычное сообщество

Доброго дня, коллеги, а вот этот кейс кто-то побеждал?
https://github.com/openshift/origin/issues/22216

Nginx container can't resolve internal DNS hostnames · Issue #22216 · openshift/origin

When using a variable to proxy to an internal Openshift service within an nginx container's proxy_pass config, NGINX can't resolve the service's DNS due to a required resolv...

источник

19:29пожаловаться #12

DM

Danila Malovichko in OpenShift - русскоязычное сообщество

Привет знатокам.
Хочу сделать грязь на окд 3.11, а именно создать cronjob с kubectl на борту, чтобы рестартить деплоймент(течет память в апликухе).
Собственно вопрос: почему может не отрабатывать job c командой kubectl rollout restart deployment/<YOUR DEPLOYMENT NAME> (connection refused), при этом в дебаг режиме все работает?
uid пользователя один и тот же, sa вроде тоже один и тот же

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployment-restart
  namespace: <YOUR NAMESPACE>
rules:
  - apiGroups: ["apps", "extensions"]
    resources: ["deployments"]
    resourceNames: ["<YOUR DEPLOYMENT NAME>"]
    verbs: ["get", "patch", "list", "watch"]


apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: deployment-restart
  namespace: <YOUR NAMESPACE>
spec:
  concurrencyPolicy: Forbid
  schedule: '0 8 * * *' 
  jobTemplate:
    spec:
      backoffLimit: 2 
      activeDeadlineSeconds: 600 
      template:
        spec:
          serviceAccountName: deployment-restart 
          restartPolicy: Never
          containers:
            - name: kubectl
              image: bitnami/kubectl 
              command:
                - 'kubectl'
                - 'rollout'
                - 'restart'
                - 'deployment/<YOUR DEPLOYMENT NAME>'

источник

21:26пожаловаться #13

R

Reggie in OpenShift - русскоязычное сообщество

Danila Malovichko

Привет знатокам.
Хочу сделать грязь на окд 3.11, а именно создать cronjob с kubectl на борту, чтобы рестартить деплоймент(течет память в апликухе).
Собственно вопрос: почему может не отрабатывать job c командой kubectl rollout restart deployment/<YOUR DEPLOYMENT NAME> (connection refused), при этом в дебаг режиме все работает?
uid пользователя один и тот же, sa вроде тоже один и тот же

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployment-restart
  namespace: <YOUR NAMESPACE>
rules:
  - apiGroups: ["apps", "extensions"]
    resources: ["deployments"]
    resourceNames: ["<YOUR DEPLOYMENT NAME>"]
    verbs: ["get", "patch", "list", "watch"]


apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: deployment-restart
  namespace: <YOUR NAMESPACE>
spec:
  concurrencyPolicy: Forbid
  schedule: '0 8 * * *' 
  jobTemplate:
    spec:
      backoffLimit: 2 
      activeDeadlineSeconds: 600 
      template:
        spec:
          serviceAccountName: deployment-restart 
          restartPolicy: Never
          containers:
            - name: kubectl
              image: bitnami/kubectl 
              command:
                - 'kubectl'
                - 'rollout'
                - 'restart'
                - 'deployment/<YOUR DEPLOYMENT NAME>'

А memory limit не стоит на деплойменте ? Тогда на OOM рестартанется сама. А по сути вопроса, похоже что не находит kubernetes service или не на тот порт к нему стучится

источник

22:21пожаловаться #14

DM

Danila Malovichko in OpenShift - русскоязычное сообщество

Так в том и прикол что в дебаг режиме все ок, а по поводу лимитов думал Но остаются зависшие соединения до Кафки :))

источник

22:23пожаловаться #15

DM

Danila Malovichko in OpenShift - русскоязычное сообщество

Я могу предположить что есть ограничения по политике доступа к апи окд, но не нашел таких...

источник

22:25пожаловаться #16

VR

Vadim Rutkovsky in OpenShift - русскоязычное сообщество

Danila Malovichko

Привет знатокам.
Хочу сделать грязь на окд 3.11, а именно создать cronjob с kubectl на борту, чтобы рестартить деплоймент(течет память в апликухе).
Собственно вопрос: почему может не отрабатывать job c командой kubectl rollout restart deployment/<YOUR DEPLOYMENT NAME> (connection refused), при этом в дебаг режиме все работает?
uid пользователя один и тот же, sa вроде тоже один и тот же

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployment-restart
  namespace: <YOUR NAMESPACE>
rules:
  - apiGroups: ["apps", "extensions"]
    resources: ["deployments"]
    resourceNames: ["<YOUR DEPLOYMENT NAME>"]
    verbs: ["get", "patch", "list", "watch"]


apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: deployment-restart
  namespace: <YOUR NAMESPACE>
spec:
  concurrencyPolicy: Forbid
  schedule: '0 8 * * *' 
  jobTemplate:
    spec:
      backoffLimit: 2 
      activeDeadlineSeconds: 600 
      template:
        spec:
          serviceAccountName: deployment-restart 
          restartPolicy: Never
          containers:
            - name: kubectl
              image: bitnami/kubectl 
              command:
                - 'kubectl'
                - 'rollout'
                - 'restart'
                - 'deployment/<YOUR DEPLOYMENT NAME>'

лимиты + preStop для закрытия коннектов?

источник

22:33пожаловаться #17

VR

Vadim Rutkovsky in OpenShift - русскоязычное сообщество

Danila Malovichko

Так в том и прикол что в дебаг режиме все ок, а по поводу лимитов думал Но остаются зависшие соединения до Кафки :))

>в дебаг режиме все ок

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

kubectl

Лучше просто взять quay.io/openshift/origin-cli:v3.11

источник

22:36пожаловаться #18

DM

Danila Malovichko in OpenShift - русскоязычное сообщество

Vadim Rutkovsky

лимиты + preStop для закрытия коннектов?

Хороший вариант, спасибо

источник

22:37пожаловаться #19

DM

Danila Malovichko in OpenShift - русскоязычное сообщество

Vadim Rutkovsky

>в дебаг режиме все ок

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

kubectl

Лучше просто взять quay.io/openshift/origin-cli:v3.11

тут не совсем понял, kubectl работает, но не может достучаться до api

источник

22:39пожаловаться #20