Helm: Область видимости освобождает имена в пространства имен

Я не уверен, что понимаю тебя. Вы хотите выполнить развертывание в нескольких пространствах имен, имея только одно название выпуска?

@ 21stio Совершенно верно . из документации Kubernetes:

Kubernetes поддерживает несколько виртуальных кластеров, поддерживаемых одним и тем же физическим кластером. Эти виртуальные кластеры называются пространствами имен.

и

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

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

Я согласен. Все мои пространства имен имеют форму ${site}-${environment} , но мои выпуски - ${site}-${environment}-${description} . Где site может быть internal или www а environment может быть dev , staging или team-a , team-b и description могут иметь вид nginx , migrations , cache и т. Д.

Но ${site}-${environment} крайне избыточно:

NAMESPACE                    NAME
www-dev                     www-dev-redis-1234567890-cj241
www-dev                     www-dev-proxy-1234567890-kfd44
www-staging                 www-staging-redis-1234567890-cj241
www-staging                 www-staging-proxy-9876543210-kfd44
internal-team-b             internal-team-b-redis-1234567890-cj241
internal-team-b             internal-team-b-nginx-1234567890-cj241

Это то, что у меня получается, но я бы предпочел, чтобы стручки были всего лишь redis-1234567890.. или proxy-9876543210..

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

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

В явном виде, было бы очень хорошо, если бы я мог делать то же самое, что и со службами и другими собственными типами k8s с помощью диаграмм управления, относящихся к пространству имен.

Например, я хотел бы иметь возможность делать следующее:

helm install --namespace abc --name redis stable/redis
helm install --namespace def --name redis stable/redis

@Janpot @bcorijn Сделанное выше предположение состоит в том, что диаграммы Helm работают только с объектами, которые инкапсулированы внутри пространств имен. Мы не хотим ограничивать Helm только этими видами ресурсов.

А как насчет сторонних ресурсов, которые не имеют пространства имен? Или RBAC, где «пространство имен» - это атрибут политики, а не местоположение (https://kubernetes.io/docs/admin/authorization/)?

Я знаю, что уже говорил об этом несколько раз в другом месте, но наша конечная цель - сделать возможным развертывание ресурсов в нескольких пространствах имен из одной и той же диаграммы. (Пример использования: приложение имеет плоскость управления и плоскость данных, и вы хотите развернуть их каждое в отдельных пространствах имен для создания границ безопасности)

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

1. Непосредственное управление пространствами имен
2. Управление RBAC и учетными записями служб
3. Управление TPR (и любыми другими объектами, не имеющими пространства имен)
4. В конечном итоге поддержка диаграмм с несколькими пространствами имен.

Я понимаю, что это немного усложняет вам проблему именования, но позволяет Helm работать с гораздо более широким спектром ресурсов Kubernetes.

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

@technosophos, чтобы подвести итог, можно
1) Управление ресурсами, не имеющими пространства имен
2) Планы на будущее по разрешению установки диаграмм в пространстве имен

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

Чтобы диаграммы с несколькими пространствами имен работали нормально / изначально, вам, скорее всего, потребуется капитальный ремонт системы пространств имен, поскольку текущая концепция Helm, помещающая выпуски в пространство имен, не сработает? _EDIT: Только что осознал, что если бы выпуски действительно были пространством имен, диаграмма с несколькими пространствами имен могла бы быть просто зонтичной диаграммой, содержащей два выпуска с другим пространством имен? _

Для управления ресурсами без пространства имен; У меня нет личного опыта с этим, поэтому немного сложно судить, но я снова чувствую, что это вынуждает Helm работать прямо сейчас, поскольку выпуск, который управляет пространствами имен, RBAC или TPR будет иметь пространство имен но просто игнорировать это?
Я мог бы просто чего-то упустить из-за отсутствия опыта работы с ними, но я бы не стал рассматривать имена и игнорировать пространство имен с тем же конечным результатом, это просто возлагало бы на пользователя больше ответственности, чтобы убедиться, что его имена выпусков и селекторы правильный / уникальный при работе с этими ресурсами. (что я согласен, это большая ответственность)

Так что, может быть, просто анализировать релизы - не лучший вариант, но стоит еще раз взглянуть на то, как они обрабатываются в Helm и будут обрабатываться в будущем? Могут ли работать оба варианта, о @Janpot: «глобальные» выпуски и выпуски с пространством имен?
Мое _ очень личное_ мнение также заключается в том, что развертывание описанным выше способом @ kylebyerly-hp, @chancez и мною встречается гораздо чаще, чем два варианта использования, которые препятствуют этому способу работы.

Во-первых, позвольте мне повторить основную мысль: диаграммы Helm работают на глобальном уровне, а не на уровне пространства имен. Так что их имена глобально уникальны.

Для диаграмм с несколькими пространствами имен нам нужно исправить возможность Тиллера выполнять запросы в пространствах имен. (На самом деле теперь вы можете _install_ диаграммы с несколькими пространствами имен. Вы просто не можете надежно обновить или удалить их, потому что Tiller не может надежно запрашивать их).

Для элементов, не связанных с именами, все будет очень сложно. У нас были бы выпуски с именами, управляющие вещами без имен, которые, в свою очередь, могли повлиять на другие пространства имен. Посмотрите, как работают RBAC и TPR. Это не те вещи, которые Helm может просто решить не поддерживать, и «подделка» пространства имен вызовет больше проблем, чем оно того стоит, особенно с RBAC.

Я до сих пор не нашел веской причины для размещения в пространстве имен имени выпуска. Ваши первоначальные жалобы основаны на неправильном понимании того, что все (важные) вещи в Kubernetes ограничены пространством имен. Но такие важные вещи, как TPR и RBAC, - нет. Основная масса других жалоб, похоже, связана с тем, что используемые ими схемы _ad hoc_ именования «не очень хороши» для Helm. Работа над этим путем создания ОГРОМНОГО нарушения совместимости, которое неверно представляет выпуски как «в пространстве имен», кажется неправильным подходом.

@technosophos

Теперь вы можете установить диаграммы с несколькими пространствами имен

Как? Где в конфиге следует поместить понятие пространств имён?

Планируете ли вы официально поддерживать выпуски с несколькими пространствами имен?

Мы не планируем полностью поддерживать выпуски с несколькими пространствами имен до Helm 3.0, потому что это нарушит обратную совместимость и потребует серьезного рефакторинга большей части кода Kubernetes Helm / Tiller.

К сожалению, для нас невозможность развертывать и управлять несколькими пространствами имен с помощью helm является преградой.

Наш план состоял в том, чтобы создать зонтичную диаграмму, в которой все наши приложения (например, меньшие диаграммы) были бы зависимостями. Все наши приложения живут в своих собственных пространствах имен, это было задумано (в будущем мы хотели бы иметь RBAC для каждого пространства имен). С помощью зонтичной диаграммы мы могли бы установить и обновить сразу весь кластер различных микросервисов, имея только один values.yml , что было бы очень удобно.

@technosophos , спасибо. Отмечено, что поддержка вышеперечисленного появится не скоро, по крайней мере, до Helm 3.0.

Есть ли общее представление о том, что именно нужно отредактировать в Helm / Tiller для поддержки нескольких пространств имен? Или 3.0 это слишком далеко?

Мы начали рассматривать helm name как нечто большее, чем UUID, используя --name-template и позволяя ему генерировать простое, но случайное имя. Я не могу сказать, что предпочитаю это уважению самого пространства имен, но я вижу обе точки, и для нас этого будет достаточно с минимальными накладными расходами.

например https://github.com/kubernetes/helm/pull/1015#issuecomment -237309305

> helm install --namespace www-dev --name-template "{{randAlpha 6 | lower}}" stable/redis

> kubectl --namespace www-dev get pods
NAME                                    READY     STATUS    RESTARTS   AGE
uvtiwh-redis-4101942544-qdvtw           1/1       Running   0          14m

> helm list --namespace www-dev
NAME    REVISION        UPDATED    STATUS          CHART                   NAMESPACE
uvtiwh  1               ...        DEPLOYED        redis-0.8.0             www-dev

@icereval, как вы найдете имя для redis (uvtiwh) в ваших приложениях, чтобы подключиться к нему?

Шаблон, который я собираюсь использовать в наших кластерах, следующий:

• Один экземпляр Tiller в kube-system , который будет использоваться администраторами кластера
• Один экземпляр Tiller на пространство имен с более ограниченными разрешениями RBAC, который будет использоваться командой разработчиков, владеющей этим пространством имен.

Принцип разработки «Названия выпусков Helm уникальны в глобальном масштабе» - головная боль для мягких многопользовательских развертываний, подобных нашему, поэтому мне интересно узнать больше о рекомендуемом подходе!

Я был очень разочарован, когда узнал, что Helm не придерживается концепции идентификации выпусков на основе их имени и пространства имен. На мой взгляд, это не соответствует принципам дизайна Kubernetes, где ресурсы уникальны в пределах своего соответствующего пространства имен (за исключением некоторых глобальных ресурсов).

Как отмечали другие авторы в этой ветке, у нас есть несколько пространств имен с суффиксами среды для разных групп приложений. У нас есть сотни различных развертываний в трех или четырех средах. Мы в значительной степени полагаемся на уникальные DNS-имена в пространствах имен, чтобы мы могли ссылаться на службы с одинаковыми именами в разных пространствах имен; например. к нашей службе redis можно получить доступ через tcp: // redis в обоих пространствах имен a-test и a-prod , где оба пространства имен имеют развернутую версию redis.

Ориентируясь на это как на предмет обсуждения для Helm 3. Похоже, на это существует огромный спрос.

Противоположное мнение:

Практически все наши деревья диаграмм развертывают артефакты в нескольких пространствах имен, разделенных по линиям persistence / API / Level7 ALB (+ static). С этой точки зрения ЛЮБЛЮ тот факт, что названия выпусков руля являются глобальными.

Обнаружил наличие опции --namespace в helm полуполезной с точки зрения сборки многослойных приложений, где базовые уровни могут быть повторно использованы красными / синими развернутыми верхними уровнями. Вместо того, чтобы вставлять производные от {{ .Release.Name }} строки в имена артефактов, мы создаем новое пространство имен для каждого развертывания. Это позволяет нам распространять детерминированно сформированные URL-адреса служб через связанные конфигурации ( same_service_name.some_product_release20171102a.svc.cluster.local > same_service_name.some_product_release20171105c.svc.cluster.local ).

Поскольку автоматически сгенерированные названия выпусков в любом случае являются чепухой - никакой точности в том, что стоит за этой штукой в helm list , мы жестко переопределяем --name строкой, полученной из названия продукта / стека и монотонно увеличивающейся версии / build version ( "appname-v20171103xyz" ) Хотелось бы иметь возможность определять значение --name-template где-нибудь на диаграмме и просто использовать имя диаграммы + производное от datetime или явное значение идентификатора сборки.

Пример

Базовый слой стойкости

apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: {{ .Values.global.product }}-persistence-{{ .Values.global.tier }}
  labels:
    app: redis
    chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
    release: "{{ .Release.Name }}"
    heritage: "{{ .Release.Service }}"
...

Потребляется из другого пространства имен, например:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: {{ .Values.global.product }}
  namespace: {{ .Release.Name }}
  labels:
    app: {{ .Values.global.product }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
...
          env:
            - name: REDIS_SERVER_HOSTNAME
----->      value: "redis.{{ .Values.global.product }}-persistence-{{ .Values.global.tier }}.svc.cluster.local"

Вышеуказанные 2 шаблона являются частями 2 отдельных диаграмм (диаграмма устойчивости и диаграмма API) и могут запускаться отдельно или совместно через третью общую диаграмму. В обоих случаях из-за использования .global. значения один раз переопределяются в командной строке и применяются ко всем поддиаграммам.

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

Одним из преимуществ наличия и использования пространств имен является то, что имена объектов (включая имена DNS) в них являются локальными и не должны переходить из пространства имен в пространство имен. В частности, в приведенном выше примере @dvdotsenko REDIS_SERVER_HOSTNAME должен быть таким же (например, просто redis ) и не должен вводить глобализированные значения. Причина в том, чтобы не повторяться.

С точки зрения простоты (и если отбросить некоторые естественно сложные случаи, такие как развертывание с несколькими пространствами имен и объекты без имен), идеальный случай состоит в том, что пространство имен «собирает» ваш стек и содержит ровно один экземпляр вашего приложения.

Это позволяет именам в стеке быть локальными, простыми и, что наиболее важно, фиксированными, поскольку они зависят от пространства имен.

Возможный подход состоит в том, чтобы helm поддерживал простой случай более или менее, как сегодня (избегая при этом префикса объектов с пространством имен); это приведет к разумному, безопасному по умолчанию передовому опыту, который будет работать из коробки для большинства применений. Он также может иметь расширенный режим пространства имен, который предоставит больше свободы (за счет сложности), чтобы разрешить варианты использования, описанные @dvdotsenko и @bcorijn .

Мои 0,02 доллара

Я должен согласиться с @pnickolov , для нас это главный блокировщик. В нашем случае использования у нас более 150 сред и несколько кластеров, которые должны запускать варианты одного и того же стека приложений. Пространства имен решают эту проблему, позволяя разделить среды и упростить настройку, особенно в отношении обнаружения служб.

Без простого способа настройки конечных точек сервисов в родственных диаграммах ... Чисто через значения ...

Меня это тоже сбивает с толку. Как пишет @technosophos :

Релиз не привязан к пространству имен. (Вот почему сам выпуск может содержать определение пространства имен). Фактически, должно быть возможно (хотя я не могу сказать, что я лично пытался) развернуть одну диаграмму, которая создает несколько объектов в нескольких пространствах имен.

Я изо всех сил пытаюсь понять это. Я просмотрел документацию, рассмотрел несколько проблем здесь, в GH, и все еще не понимаю:

• С одной стороны, я могу использовать helm install --namespace чтобы указать пространство имен, на которое я хотел бы настроить таргетинг.
• С другой стороны, моя диаграмма может указывать любые пространства имен внутри своих объектов метаданных.

Итак, мои вопросы:

• Если пространство имен, указанное в helm install --namespace , не существует, создает ли его Helm? Затем он устанавливает это пространство имен для всех ресурсов, которые он создает из chrt?
• Если шаблон ресурса указывает пространство имен в своих метаданных, перезаписывает ли его helm?

Эти вопросы заставили меня не решаться даже играть с --namespace , это так непонятно. Если кто-нибудь может помочь мне разобраться в этом, я был бы очень признателен. Спасибо!

f пространство имен, указанное helm install --namespace, не существует, создает ли его Helm?

да. Если пространство имен еще не существует, --namespace создает указанное пространство имен для диаграммы.

Если шаблон ресурса указывает пространство имен в своих метаданных, перезаписывает ли его helm?

Нет. Если вы предоставите то же пространство имен в --namespace а также ресурс пространства имен в диаграмме, возникнет конфликт, поскольку пространство имен будет сначала установлено tiller, а затем bork, когда диаграмма попытается переустановите то же пространство имен еще раз.

Для дальнейшего контекста идея helm состоит в том, чтобы установить все ресурсы в пространстве имен, предоставляемом helm install --namespace . Пользователи, которые «жестко кодируют» пространство имен в диаграмме, обычно хотят установить диаграмму в нескольких пространствах имен.

Это немного не по теме того, что предлагает OP, но, пожалуйста, не стесняйтесь открывать новый тикет или присоединяться к нам в Slack, если у вас есть дополнительные вопросы! :)

Не уверен, что хочу влезть в эту дискуссию 😄 Будьте добры, пожалуйста 🙏

Параметр helm --namespace на самом деле является --default-namespace

При чтении стека и связанного с ним появляется много путаницы вокруг опции --namespace потому что люди (вполне разумно) предполагают, что это похоже на kubectl --namespace , к которому они привыкли, что эффективно ограничивает активность этим пространством имен ( побочный эффект ошибки синтаксического анализа, а не безопасность). Это не относится к helm поскольку tiller - это служба кластера, которая работает во всем кластере. Вариант лучше было бы назвать --default-namespace , т.е. это пространство имен, в которое будут переходить ваши ресурсы, если в них не указано конкретное пространство имен.

Также необходимы выпуски с несколькими пространствами имен

Я уже полагаюсь на диаграммы, которые развертывают различные компоненты каждого выпуска в нескольких пространствах имен, и с нетерпением жду расширенной поддержки в helm 3.0. 👍 🎉

Мультитенант с ограничениями на управление и пространство имен уже возможен

Я также вижу вариант использования, когда люди хотят установки с несколькими арендаторами и ограничением пространства имен. ИМХО, ограничение или ограничение выпусков пространствами имен - это не то, что helm / tiller должно заботиться о соблюдении, это задача RBAC. Для этого есть как минимум две модели, одна из них возможна прямо сейчас:

1. Разверните пространство имен tiller с учетной записью службы и RBAC, которое разрешает операции только в этом пространстве имен. Сейчас это работает, и я вижу, как люди его используют. Идеально подходит для мультитенантных кластеров.
2. За tiller для поддержки олицетворения пользователя k8s и развертывания каждого выпуска как пользователя helm . Это обсуждается для будущих версий helm и, похоже, имеет некоторые проблемы с реализацией. Но это позволит кластерной службе tiller применять ограничения пространства имен RBAC, при этом поддерживая выпуски, охватывающие несколько пространств имен.

Ресурсы с одинаковыми именами для разных выпусков в разных пространствах имен уже возможны

Для людей, желающих установить одну и ту же диаграмму в разные пространства имен, но с одинаковыми именами ресурсов (например, redis). Это вполне возможно, это зависит от того, как вы пишете свои шаблоны диаграмм. Вам не нужно ставить перед именами ресурсов префикс с названием выпуска, это просто стандарт / соглашение, которому следуют многие диаграммы. В последних диаграммах уже есть значение .fullnameOverride которое позволяет исключить префикс имени выпуска. Вы можете развернуть свой redis как redis с каждым helm install если хотите.

Мы находимся в той же ситуации, что и @gmile, и мы хотели знать, как лучше всего это делать. Наше основное приложение, ingestion-service , зависит от kafka которое, в свою очередь, зависит от zookeeper . Но мы хотим, чтобы все три были в их собственных пространствах имен, но мы хотим управлять через один хелм install . Мы планировали добавить kafka в requirements.yaml из ingestion-service . Но получить kafka в собственном пространстве имен не так просто с helm поэтому мы решили удалить из requirements.yaml и иметь разные helm install для обоих развертываний. .

Просто к сведению, что это отмечено и является частью предложения Helm 3, перечисленного в разделе 3: Государственное управление . Обратная связь приветствуется!

Это фантастическая новость @bacongobbler 😄🎉

@bacongobbler. Ищет ли Helm 3 поддержку указания отдельных пространств имен для зависимых диаграмм в файле requirements.yaml, как описано в

Из документа предложения (прочтите его!: Smile :):

$ helm install -n foo bar --namespace=dynamite
# installs release, releaseVersion, and un-namespaced charts into dynamite namespace.

Как и в случае с Helm 2, если ресурс явно объявляет собственное пространство имен (например, с помощью metadata.namespace = something), Helm установит его в это пространство имен. Но поскольку ссылки владельцев не относятся к пространствам имен, любой такой ресурс в основном станет неуправляемым.

@bacongobbler Я читал это, но до сих пор не вижу, чтобы он поддерживал это. Я не имею в виду жестко запрограммированные метаданные. Пространство имен в диаграммах, которые я контролирую, это всегда поддерживалось. Я имею в виду указание пространства имен для сторонней диаграммы, которую у меня нет возможности редактировать. Например, в моем файле requirements.yaml я использую stable / kubernetes-dashboard и хочу, чтобы он был установлен в систему kube, но моя диаграмма должна перейти в пространство имен разработки.

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если сейчас проблему можно безопасно закрыть, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл устаревший

Похоже, что именно этот запрос функции может быть выполнен с помощью helmfile . Из того, что находится в файле readme, должно быть возможно указать разные выпуски, ограниченные собственными пространствами имен.

@gmile Я на 99% уверен, что разработчики helmfile не исправили эту проблему в helmfile. Если вы объявите два выпуска с именем vault с разными пространствами имен в вашем helmfile.yaml и запустите helmfile sync , это не удастся, потому что имя выпуска vault было заявлено первым выпуском.

отказ от ответственности: я не тестировал это с помощью helmfile, поэтому мне бы хотелось, чтобы мне сказали, что я ошибаюсь. 😄

На всякий случай, если последний комментарий был пропущен, мы исправляем это в Helm 3, внося изменения в то, как Helm обрабатывает выпуски . :)

@ steven-sheehy эту конкретную проблему, вероятно, можно было бы исправить с помощью модели песочницы , расширив поддиаграмму для развертывания в определенном пространстве имен, чем определено.

/ remove-жизненный цикл устаревший

По теме: https://discuss.kubernetes.io/t/timeline-for-helm-3/2776

Реализовано в Helm 3. Изменение контекста пространства имен полностью относится к другому экземпляру.

><> ./bin/helm version
version.BuildInfo{Version:"v3.0+unreleased", GitCommit:"5eb48f4471ac3aa9a3c87a07ee6f9e5bbc60a0e1", GitTreeState:"clean"}
><> ./bin/helm list --all-namespaces
NAME            REVISION    UPDATED                                 STATUS      CHART               NAMESPACE
chartmuseum     1           2019-02-08 08:56:29.566393188 -0800 PST deployed    chartmuseum-1.9.0   default  
chartmuseum     1           2019-02-08 09:14:01.978866327 -0800 PST deployed    chartmuseum-1.9.0   foo

Отличные новости

Учитывая это изменение, имеет ли смысл перемещать столбец пространства имен в первый столбец в выходных данных list . Чтобы первые два столбца однозначно определяли выпуск?

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

Конечно.

пока я просто использую

helm install --name <namespace>-<name> ...

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

Хорошо, похоже, есть 3 основных сценария (с возможностью смешивания различных перестановок каждый):

1. диаграмма с единым пространством имен.
2. ресурс, который не имеет пространства имен.
3. диаграмма с несколькими пространствами имен.

Будет ли это разумным подходом для решения различных сценариев:

1. ввести / переопределить пространство имен при поставке с флагом --namespace .
2. То же, что и 1, но игнорирует пространство имен для тех ресурсов, которым не хватает пространства имен.
3. при выходе цитируется «невозможно переопределить ресурс с несколькими пространствами имен» или что-то подобное.

Кроме того: я не использую культиватор, предпочитаю helm template поэтому не уверен, насколько это меняет проблемы.

@technosophos

Я пытаюсь понять, как Helm v2 взаимодействует с пространствами имен и чем v3 будет отличаться, и один из ваших старых комментариев в этой ветке смущает меня:

Во-первых, позвольте мне повторить основную мысль: диаграммы Helm работают на глобальном уровне, а не на уровне пространства имен. Так что их имена глобально уникальны.

....

Для элементов, не связанных с именами, все будет очень сложно. У нас были бы выпуски с именами, управляющие вещами без имен, которые, в свою очередь, могли повлиять на другие пространства имен. Посмотрите, как работают RBAC и TPR. Это не те вещи, которые Helm может просто решить не поддерживать, и «подделка» пространства имен вызовет больше проблем, чем оно того стоит, особенно с RBAC.

Похоже, что выпуски, развернутые из Helm v3, на самом деле будут иметь пространство имен; это правильно? Вы знаете, как была решена проблема с RBAC? Единственное решение, которое я могу придумать, чтобы избежать проблемы, на которую вы указали, - это то, что диаграммы Helm v3 не поддерживают изменение объектов RBAC, но я не нашел ничего в различных сообщениях в блогах и тому подобном о v3, указывающем, будут ли диаграммы v3 поддерживать управление RBAC возражает или нет.

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

Я не читал предложения по helm v3, но разумно сделать
принять шаблон селектора, который уже использует k8s, и нет необходимости
поддерживать любые конкретные поля.

Во вторник, 25 июня 2019 г., 11:01 BatmanAoD [email protected] написал:

@technosophos https://github.com/technosophos

Я пытаюсь понять, как Helm v2 взаимодействует с пространствами имен и как v3
будет другим, и меня смущает один из ваших старых комментариев в этой ветке:

Во-первых, позвольте мне повторить основную мысль: диаграммы Helm работают с глобальным
уровень, а не на уровне пространства имен. Так что их имена глобально уникальны ....

Для элементов, не связанных с именами, все будет очень сложно. У нас было бы
выпуски с именами, управляющие вещами без имен, которые, в свою очередь, могут
влияют на другие пространства имен. Посмотрите, как работают RBAC и TPR.
Это не те вещи, которые Хелм может просто решить не поддерживать, и
"подделка" пространства имен вызовет больше проблем, чем оно того стоит, особенно
с RBAC.

Похоже, что выпуски, развернутые из Helm v3, на самом деле будут иметь пространство имен;
это правильно? Вы знаете, как была решена проблема с RBAC? Единственный
разрешение, которое я могу придумать, чтобы избежать проблемы, о которой вы указали, для
Диаграммы Helm v3 не поддерживают изменение объектов RBAC, но я не нашел
что-нибудь в различных сообщениях блога и тому подобное о v3, указывающее,
диаграммы будут поддерживать управление объектами RBAC или нет.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREXHFSKFSB7FXQ5VPTP4JMP3A5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43LNTVBWW
или отключить поток
https://github.com/notifications/unsubscribe-auth/AACFHRH2JPXPKMX23WVQLCDP4JMP3ANCNFSM4DCII7XQ
.

@BatmanAoD @gyndick В Helm v3 диаграммы устанавливаются в контексте пользователя. Это означает, что он установлен в этом пространстве имен пользователя и будет использовать RBAC пользователя. Имена версий также основаны на пространстве имен.

Вы можете попробовать его с выпуском Alpha.1: https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 или собрать из ветки dev-v3 .

Я не буду использовать helm v3. У каждой операционной группы разные
ограничения и способы делать что-либо. Операционные инструменты должны быть простыми,
одноцелевые утилиты, т.е. совместимые с философией Unix.

Мои сценарии, логика и т. Д. Живут вне моего диспетчера пакетов.

TL; DR;

Наиболее важным аспектом совместимости с философией Unix является
возможность обеспечения аварийных люков между ступенями.

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

Сложность, предложенная для v3, повлечет за собой много ошибок и плохих
дизайн от людей, у которых нет 25-летнего опыта.

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

Прекрасный пример - когда кто-то кодифицирует в одну огромную, ужасную
письменный сценарий. Произошел сбой, и нужно запустить часть скрипта,
других частей нужно строго избегать, но они являются неотъемлемой частью
основная логика. Что, черт возьми, ты тогда делаешь? Сидеть там отчаянно пытаясь
для рефакторинга кода, который у вас действительно нет хорошего способа отладки.

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

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

Менеджер пакетов должен быть простым и легким с несколькими
обязанности.

1. Доставить артефакты
2. Удалить артефакты
3. Запустите скрипты, предоставленные в артефактах
4. Следите за артефактами, которые, по его мнению, были доставлены
5. Самое главное, KISS

Все остальное требует боли. Откровенно говоря, helm v2 был бы почти идеален
если бы он просто исправил, как он отслеживал выпуски.

В среду, 26 июня 2019 г., 01:31 Мартин Хики [email protected]
написал:

@BatmanAoD https://github.com/BatmanAoD @gyndick В Helm v3 диаграммы
установлен в контексте пользователя. Это означает, что он установлен у этого пользователя
пространство имен и будет использовать RBAC пользователя. Названия релизов находятся на
база имен также.

Вы можете попробовать это в версии Alpha.1:
https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 или соберите из
ветка dev-v3.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREUTX77SJCPWZLQKATP4MSNRA5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVORWW63L2HS4DFVREXG43VMVORWW63L2HS4DFVREXG43VMVBWW63L2HS4DFVREXG43VMVBW63L
или отключить поток
https://github.com/notifications/unsubscribe-auth/AACFHRCAQLWUYHH6RJSUYF3P4MSNRANCNFSM4DCII7XQ
.

@hickeyma Спасибо за ответ! На самом деле меня не так сильно интересует, как операции Helm будут контролироваться (хотя это родственная проблема), а сможет ли сам Helm по-прежнему выполнять глобальные операции, такие как создание ClusterRoles в v3.

@BatmanAoD Это должно работать, поскольку они являются ресурсами с кластерной областью. Возможно, стоит попробовать, если у вас будет возможность.