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

@bacongobbler извиняюсь за задержку. Понятно, что с помощью minikube труднее воспроизводить локально, поскольку у нас есть все, что настроено для / с AWS EKS. На данный момент я могу подтвердить, что apiVersion serviceMonitor не меняется, поэтому, похоже, это не связано с # 6583 .

Когда я запускаю шаблон helm в первый раз:

# Source: k8s-service/templates/servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: bid-management
  namespace: dcd
  labels:
    chart: k8s-service-v0.0.11
    app: bid-management
    heritage: "Helm"
    release: prometheus
spec:
  endpoints:
      - honorLabels: true
        interval: 10s
        path: /prometheus
        port: metrics
        scheme: http
        scrapeTimeout: 10s
  selector:
    matchLabels:
      app.kubernetes.io/name: bid-management

После обновления и успешного создания ресурса я снова запускаю шаблон helm и получаю следующее ниже:

# Source: k8s-service/templates/servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: bid-management
  namespace: dcd
  labels:
    chart: k8s-service-v0.0.11
    app: bid-management
    heritage: "Helm"
    release: prometheus
spec:
  endpoints:
      - honorLabels: true
        interval: 10s
        path: /prometheus
        port: metrics
        scheme: http
        scrapeTimeout: 10s
  selector:
    matchLabels:
      app.kubernetes.io/name: bid-management

После повторного запуска обновления руля я получаю сообщение об ошибке, упомянутой выше.

Error: UPGRADE FAILED: rendered manifests contain a new resource that already exists. Unable to continue with update: existing resource conflict: kind: ServiceMonitor, namespace: dcd, name: bid-management

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

Здесь та же проблема. @bacongobbler , @ efernandes-ANDigital
версия kubectl: 1.14.7
kubernetes версии 1.15 (PKS)
Первый раз случился со мной, используя Helm v3.0.0-rc.1, после обновления до Helm v3.0.0-rc.2 это все еще происходит.
Успешно выполнен откат к предыдущему состоянию с помощью rc.2 и выполнено повторное обновление, но проблема не решена: после успешного обновления попытка нового обновления выдала то же сообщение об ошибке.
helm diff не показывает никаких проблем (он правильно определяет ресурсы), и даже если я загляну внутрь секрета, связанного с ревизией, он показывает ресурсы там, поэтому он не должен пытаться повторно развернуть их.
Не сложная диаграмма, просто использование диапазона для итерации списка (~ 100 элементов) для генерации некоторых ресурсов (пространства имен, конфигурационные карты и т. Д.)

Не могу перепрограммировать (пробовал на GKE)

@aespejel На kind ресурсах произошел сбой?

Пространства имен, что имеет смысл, имея в виду, что штурвал порядка пытается применить манифесты, верно @ thomastaylor312 ?

Да, сначала идут пространства имен, но я просто проверял, происходит ли это с конкретными видами ресурсов или с ассортиментом

Чтобы добавить, мы заметили кое-что еще при отключении монитора службы. При запуске обновления helm он возвращает сообщение об успешном завершении обновления. «Освободить« управление ставками »было обновлено. Удачного Helming! И т. Д. Однако после проверки api-resources servicemonitors мы все еще видим созданный servicemonitor.

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

Проблема также возникает при попытке установить диаграмму (например, prometheus-operator), если установка не удалась, и вы попытались установить ее снова, helm жалуется на конфликт ресурсов, а если вы пытаетесь удалить диаграмму, жалуется, что она никогда не была развернута .

@vakaobr Я сомневаюсь, что это та же проблема. Когда первая установка не удалась (и только при первой установке), как вы заметили, helm не выпускает релиз. Следовательно, helm не будет иметь никакой информации о выпуске для сравнения с уже развернутыми ресурсами и попытается установить их, показывая это сообщение, потому что на самом деле некоторые ресурсы были установлены. Вероятно, вы можете решить эту проблему, используя --atomic при установке или используя helm upgrade --install --force, будьте осторожны с --force, поскольку она удалит и воссоздает ресурсы.
Здесь мы сталкиваемся с проблемой, которая возникает с уже успешно установленными диаграммами.

Обновление: все еще происходит после обновления до helm v3.0.0 (стабильная). @ efernandes-ANDigital, @bacongobbler , @ thomastaylor312
Если я использую helm diff, он НЕ показывает различий, если я использую helm upgrade --install --dry-run, он завершается ошибкой со следующей ошибкой: «Ошибка: UPGRADE FAILED: обработанные манифесты содержат новый ресурс, который уже существует».
Использование helm get manifest (последней версии) показывает эти ресурсы.
Использование шаблона helm также показывает эти ресурсы.
Может быть, это связано с тем, как helm сравнивает ресурсы с манифестом и шаблонами?
Я создаю ресурсы, повторяющие список с диапазоном, может ли это быть связано с этим?
Может быть, этот кусок кода ?

Обходной путь:
Запуск обновления --install с параметром --dry-run --debug и -v 10 показал нам, что helm каким-то образом использует некоторые действительно старые версии. Мы удалили все ревизии, кроме двух последних, и все снова заработало.

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

Я получаю эту ошибку при попытке изменить версию развертывания api на apps/v1 с устаревшей extensions/v1beta1 . Helm отказывается выполнять развертывание, если я вручную не удаляю старое развертывание.

@sheerun , вы видели мой ответ относительно изменений apiVersion в этом комментарии: https://github.com/helm/helm/issues/6646#issuecomment -547650430?

Суть в том, что вам нужно вручную удалить старый объект, чтобы «обновить». Две схемы несовместимы друг с другом и, следовательно, не могут быть обновлены с одной на другую чистым способом. Известны ли вам какие-либо инструменты, которые справятся с этим делом?

На самом деле это не помогает, потому что мне все еще нужно вручную удалять старые ресурсы. Я ожидал, что этот флаг для команды helm update такой как --force , автоматически удалит и добавит ресурсы, несовместимые с api, но это не так. Это делает обновление приложений в кластерах Kubernetes очень громоздким. Если --force не несет ответственности за это, тогда будет полезен другой флаг.

Это очень важная проблема прямо сейчас, потому что kubernetes 1.16 просто отказывается от поддержки старых API, поэтому нам нужно обновиться.

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

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

какие-нибудь обновления по этому поводу?

7082 должен обработать этот случай, если кто-то хочет начать работу над этой функцией.

Если вам нужно использовать эти обходные пути: https://github.com/helm/helm/issues/6646#issuecomment -546603596, вы можете использовать следующий скрипт, который я создал для автоматизации этого процесса: https://github.com/helm/helm/issues/6646#issuecomment -546603596. com / techmexdev / 5183be77abb26679e3f5d7ff99171731

аналогичная ошибка

• воспроизвести шаг
  Я установил 10 ревизий, когда я установил новые поддиаграммы в ревизии 11, развернул ОК.
  затем обновите снова с теми же диаграммами, helm жалуется rendered manifests contain a new resource that already exists .
• причина
  helm сравните текущую ревизию с первой развернутой ревизией, в которой нет ресурсов, которые мы только что установили в последней ревизии
• исправить
  использовать последнюю развернутую ревизию как currentRelease вместо первой ревизии

• работать вокруг
  удалить старые секреты, которыми владеет helm kubectl get secret -L owner=helm

@ jason-liew Этот вопрос касается другого, не связанного с количеством выпусков. Вы исправляете другую ошибку с аналогичной ошибкой. Эта ошибка связана с изменением версии api ресурса.

@sheerun, извините, я удалил ссылку в сообщении фиксации и отредактировал комментарий выше

У меня такая же проблема. Производственный env заблокирован и не может быть исправлен.
версия $ helm
version.BuildInfo {Версия: "v3.0.2", GitCommit: "19e47ee3283ae98139d98460de796c1be1e3975f", GitTreeState: "clean", GoVersion: "go1.13.5"}
Ошибка: ОБНОВЛЕНИЕ НЕ выполнено: обработанные манифесты содержат новый уже существующий ресурс. Невозможно продолжить обновление: конфликт существующих ресурсов: вид: служба, пространство имен: мое пространство имен, имя: моя-служба

Также Amazon EKS

Пожалуйста, добавьте «Внимание! Существует риск получить кирпич вместо диаграммы после обновления» в https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/

Отличная работа, ребята. Я горжусь!

Тоже столкнулся с этой проблемой.

После перехода на v3 с плагином helm-v2-to-helm-v3 я не могу обновлять графики:

Error: UPGRADE FAILED: rendered manifests contain a new resource that already exists. Unable to continue with update: existing resource conflict: kind: Deployment, namespace: default, name: grafana-main

Это было бы совершенно понятно, если бы это произошло в бета-версии, но я запускаю v3.0.2 после выполнения инструкций в официальном блоге, обнаруживая проблему / ошибку, о которой сообщалось во время бета-версии. Это неприятно.

Есть ли на данный момент неразрушающий ремонт? То, что предлагает этот комментарий, кажется довольно разрушительным https://github.com/helm/helm/issues/6646#issuecomment -546603596

Также возникает та же проблема при обновлении ресурса до новой версии API с помощью helm3.

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

Helm 3.0.2. Невозможно выполнить развертывание или даже откат, если предыдущее развертывание изменило количество развертываний (было удалено или добавлено развертывание). Сбой с ошибкой:

Ошибка: не найдено развертывание с именем "server2"

Крайне неприятно.

Я согласен. Разочаровывает, что Kubernetes API рассматривает обновление apiVersion как критическое изменение.

Если кому-то известно о решении в Kubernetes, которое позволяет обновлять apiVersions без повторного создания объекта, мы хотели бы услышать об этом. В настоящее время нам неизвестна конечная точка API, доступная для сторонних инструментов, таких как Helm, для «преобразования» объекта из одной версии API в другую.

Единственная возможность, о которой мы знаем из API Kubernetes, - это удалить и создать объект. Это, конечно, не идеально, но это единственный вариант, о котором мы знаем в настоящее время.

В https://github.com/helm/helm/issues/7219 было упомянуто, что при обновлении Kubernetes 1.15 до 1.16 объекты были перенесены из устаревшей версии apiVersion (например, extensions/v1beta1 ) в apps/v1 на бэкэнд. Если бы кто-то мог подтвердить это поведение, а также лучше понять, как Kubernetes достигает этого, это могло бы дать нам возможное решение этой проблемы.

Я попытался выполнить повторное развертывание с другой машины (не той, на которой ранее было развернуто измененное количество развертываний), и все прошло гладко. Может быть проблема с локальным кешированием?

@youurayy Вы используете наборы с

Здесь я столкнулся с той же проблемой. К вашему сведению, я перешел с v2 на v3. Сначала это не сработало, так как он жаловался, что некоторые API-интерфейсы недействительны. Я обновляю API-интерфейсы (Deployments и Statefulsets), и тогда у меня возникла эта проблема.

Используемая версия Helm - 3.0.2

Здесь та же проблема. Не похоже, что пиар открыли. Кто-нибудь работает над этим?

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

@bacongobbler Это какое-то большое дело, не так ли? Если я не ошибаюсь, у вас нет выбора с helm3, чтобы изменить ваши версии api с v1beta1 на v1 из-за проверки OpenAPI, так что не означает ли это, что все, кто использует helm, в значительной степени должны удалить развертывания перед обновлением диаграммы?

На самом деле, это может быть не такой большой проблемой, как я думал, отказ от --force избавляет от части проблемы, поскольку это обходит 3-стороннее слияние. Я считаю, что единственная нерешенная проблема заключается в том, что если у вас установлена ​​диаграмма Helm 2, которая использует более старый api ver k8s, то есть v1beta1, вы не можете выполнить обновление Helm 3, чтобы сказать v1.

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

Error: UPGRADE FAILED: rendered manifests contain a new resource that already exists. Unable to continue with update: existing resource conflict: kind: ServiceAccount, namespace: default, name: my-program
--
306 | helm.go:76: [debug] existing resource conflict: kind: ServiceAccount, namespace: default, name: my-program
307 | rendered manifests contain a new resource that already exists. Unable to continue with update

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

У меня возникла аналогичная ошибка при попытке изменить версию api приложений DaemonSetto / v1 с устаревших расширений / v1beta1. Helm3 отказывается обновлять DaemonSet с версии extension / v1beta1 до apps / v1.

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

Ошибка: ОБНОВЛЕНИЕ НЕ выполнено: обработанные манифесты содержат новый уже существующий ресурс. Невозможно продолжить обновление: конфликт существующих ресурсов: вид: DaemonSet, пространство имен: kube-system, имя: omsagent

Helm2 выполняет обновление без каких-либо проблем.

Я пробовал со всеми выпущенными версиями Helm3, но безуспешно.

Спасибо за решение этой проблемы в Helm3.

@ ganga1980 это не omsagent в вашем случае), пока он не сработает. опять же, не идеально, но в конечном итоге он будет работать, когда конфликтующие ресурсы, использующие устаревшие версии API, больше не существуют, и он воссоздает ресурсы с использованием обновленной версии API. мы на Kubernetes v1.15 и Helm 3.0.2.

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

Та же проблема здесь, обновите stable/nginx-ingress running:

# helm upgrade nginx-ingress stable/nginx-ingress --set rbac.create=true --set controller.publishService.enabled=true --set controller.tcp.configMapNamespace=tcp-services

выход:
Ошибка: ОБНОВЛЕНИЕ НЕ выполнено: обработанные манифесты содержат новый уже существующий ресурс. Невозможно продолжить обновление: конфликт существующих ресурсов: вид: ClusterRole, пространство имен:, имя: main-nginx-ingress

# helm version

выход:
version.BuildInfo {Версия: "v3.0.0", GitCommit: "e29ce2a54e96cd02ccfce88bee4f58bb6e2a28b6", GitTreeState: "clean", GoVersion: "go1.13.4"}

Я согласен. Разочаровывает, что Kubernetes API рассматривает обновление apiVersion как критическое изменение.

Если кому-то известно о решении в Kubernetes, которое позволяет обновлять apiVersions без повторного создания объекта, мы хотели бы услышать об этом. В настоящее время нам неизвестна конечная точка API, доступная для сторонних инструментов, таких как Helm, для «преобразования» объекта из одной версии API в другую.

Единственная возможность, о которой мы знаем из API Kubernetes, - это удалить и создать объект. Это, конечно, не идеально, но это единственный вариант, о котором мы знаем в настоящее время.

В # 7219 упоминалось, что при обновлении Kubernetes 1.15 до 1.16 объекты были перенесены из устаревшей версии apiVersion (например, extensions/v1beta1 ) в apps/v1 на бэкэнде. Если бы кто-то мог подтвердить это поведение, а также лучше понять, как Kubernetes достигает этого, это могло бы дать нам возможное решение этой проблемы.

В чем здесь настоящая проблема? Можно без проблем выполнить обновление объекта с помощью kubectl даже с изменениями api. Объект не нужно удалять (можно просто применить / заменить kubectl), почему Helm не может сделать то же самое?

@bacongobbler Я согласен с тем, что с точки зрения
Например, в одном кластере 1.14, если развертывание создано в версии «apps / v1», оно также доступно в версиях «apps / v1bet1», «apps / v1bet2», «extensions / v1beta1». См. Https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/#deployment -v1-apps.
Так что я думаю, что дизайн helm3 с gvk нормален, но реализация должна быть более сложной. Старый объект выпуска должен быть получен не только из хранилища выпусков Helm, но и из текущей рабочей среды.

Спасибо

Я согласен. Разочаровывает, что Kubernetes API рассматривает обновление apiVersion как критическое изменение.

Если кому-то известно о решении в Kubernetes, которое позволяет обновлять apiVersions без повторного создания объекта, мы хотели бы услышать об этом. В настоящее время нам неизвестна конечная точка API, доступная для сторонних инструментов, таких как Helm, для «преобразования» объекта из одной версии API в другую.

Единственная возможность, о которой мы знаем из API Kubernetes, - это удалить и создать объект. Это, конечно, не идеально, но это единственный вариант, о котором мы знаем в настоящее время.

В # 7219 упоминалось, что при обновлении Kubernetes 1.15 до 1.16 объекты были перенесены из устаревшей версии apiVersion (например, extensions/v1beta1 ) в apps/v1 на бэкэнде. Если бы кто-то мог подтвердить это поведение, а также лучше понять, как Kubernetes достигает этого, это могло бы дать нам возможное решение этой проблемы.

Одиночный объект k8s может конвертировать из одной версии в другую, если они совместимы. См. Пример https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/apps/v1/conversion.go .

Я столкнулся с проблемой, связанной с этим.

В моем случае я включил контроллер допуска NamespaceAutoProvision чтобы избежать сбоев из-за несуществующих пространств имен. В основном это помогло, но здесь возникла новая проблема: в наших диаграммах мы явно создали несколько пространств имен, чтобы установить на них некоторые метки, которые используются для сетевых политик. Это было сделано как отдельный шаг перед установкой диаграмм, использующих эти пространства имен. С Helm 3 и контроллером NamespaceAutoProvision установка диаграммы теперь не выполняется с

Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: kind: Namespace, namespace: , name: monitoring

что имеет смысл, но блокирует подготовку. Я пробовал это с и без --force с тем же результатом.

Я не знаю, было ли это размещено раньше, но, возможно, есть способ сказать Helm «принять» ресурсы, если они уже существуют - т.е. в случае существующего пространства имен оно будет исправлено с помощью манифеста, предоставленного пользователем, и понятно, что с этого момента Хельм управляет им.

Одиночный объект k8s может конвертировать из одной версии в другую, если они совместимы. См. Пример https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/apps/v1/conversion.go .

Это преобразование из apps / v1 в другое внутреннее представление. Вы не можете использовать это для преобразования из v1beta1 в v1. Посмотрите на код повнимательнее.

Например, в одном кластере 1.14, если развертывание создано в версии «apps / v1», оно также доступно в версиях «apps / v1bet1», «apps / v1bet2», «extensions / v1beta1».

Кластеры Kubernetes поддерживают несколько версий API, но рассматриваются как отдельные дискретные объекты. Внутренние схемы совершенно разные. В настоящее время нам известно об API «конвертировать из v1beta1 в v1».

Я не знаю, было ли это размещено раньше, но, возможно, есть способ сказать Helm «принять» ресурсы, если они уже существуют - т.е. в случае существующего пространства имен оно будет исправлено с помощью манифеста, предоставленного пользователем, и понятно, что с этого момента Хельм управляет им.

См. № 2730

@bacongobbler благодарит вас за ответы и помощь. У меня такая же проблема с версией api, но в самом кластере наше развертывание - apiVersion: apps / v1
В новой версии диаграммы также есть: apiVersion: apps / v1
Но в метаданных / выпуске Helm 3 у нас есть следующее:
apiVersion: extension / v1beta1
вид: Развертывание

На самом деле неудобно, что вам нужно переустанавливать рабочую нагрузку только для исправления метаданных Helm, поскольку реальное развертывание имеет правильную версию API. Есть предложения здесь? Я подумываю настроить метаданные вручную.

Есть предложения здесь?

https://github.com/helm/helm/issues/7219#issuecomment -568175917

@bacongobbler
Я покажу, как кубернеты обрабатывают несколько версий API от дизайна, кода и времени выполнения.

1. Desing doc
   https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md#operational -overview.
   В документе есть пример того, как создать ресурс в v7beta1 и получить в v5. Таким образом, с точки зрения дизайна Kubernetes, он позволяет преобразовывать один объект из нескольких версий.

   Процесс преобразования логически представляет собой «звезду» с внутренней формой в центре. Любой версионный API можно преобразовать во внутреннюю форму (и наоборот)

2. Исходный код Kubernetes
   Как я уже говорил выше, есть такие преобразования
   https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/apps/v1/conversion.go Convert_v1_DeploymentSpec_To_apps_DeploymentSpec и Convert_apps_DeploymentSpec_To_v1_DeploymentSpec
   Также https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/apps/v1beta2/conversion.go Convert_v1beta2_DeploymentSpec_To_apps_DeploymentSpec и Convert_apps_DeploymentSpec_To_v1beta2_DeploymentSpec .
   Код использует внутреннюю структуру данных в качестве концентратора в разных версиях.

3. Поведение во время выполнения
   Я использую кластер 1.14 и kubectl.
   kubectl get -n kube-system deployment coredns -o yaml -v 8
   Принудительно использовать другую версию API
   kubectl get -n kube-system deployment.v1.apps coredns -o yaml -v 8
   Вы можете видеть, что один объект (по его uid) может быть получен несколькими версиями API.

Привет,

У меня такая же проблема. Моя проблема связана с уже существующим набором с отслеживанием состояния. Любые советы будут высоко ценится.

Спасибо,
Ричард

Давайте начнем обсуждение:
https://github.com/helm/helm/pull/7575

Привет,

Я столкнулся с той же проблемой, единственное, что я думаю, я обновился с Helm 2.14.1 до последней версии, мы получаем ошибку, как упомянуто выше: отображаемые манифесты содержат ресурс, который уже существует.

Спасибо
Hany

Вот грязный прием, который мы используем всякий раз, когда ресурс, такой как PV или PVC, уже существует, и мы не хотим его удалять, но хотим обновить контейнеры. Обычно это происходит, когда мы выполняем helm upgrade whatever и старое развертывание и новое развертывание застревают в гонке.

kubectl get deployments -n monitoring
kubectl get -n monitoring deployment/prometheus-operator-grafana -o jsonpath="{.spec.replicas}"

# Set spec.replicas to 0
kubectl edit -n monitoring deployments/prometheus-operator-grafana
watch -n1 -d "kubectl get pods -n monitoring"

# Once all pods have terminated, set the spec.replicas back to 1 or whatever value you want
kubectl edit -n monitoring deployments/prometheus-operator-grafana
watch -n1 -d "kubectl get pods -n monitoring"

# At this point you'll have an updated pod/deployment/whatever

Я получил эту ошибку, следуя базовому руководству

Нажатие этого на ClusterRoleBinding при установке диаграммы панели инструментов kubernetes

Error: UPGRADE FAILED: rendered manifests contain a new resource that already exists. Unable to continue with update: existing resource conflict: namespace: , name: kubernetes-dashboard, existing_kind: rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding, new_kind: rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding

Та же проблема при установке диаграммы в двух пространствах имен. Моя диаграмма зависит от диаграммы оператора прометея, которая создаст ClusterRole.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: kind: ClusterRole, namespace: , name: p8s-operator

То же самое. Я перенес helm2 в развертывание helm 3, после чего его больше нельзя обновить из-за той же ошибки.

./helm upgrade public-nginx-ingress stable/nginx-ingress --install --namespace ingress --wait -f public-nginx-ingress.yaml coalesce.go:199: warning: destination for extraContainers is a table. Ignoring non-table value [] coalesce.go:199: warning: destination for extraVolumes is a table. Ignoring non-table value [] coalesce.go:199: warning: destination for extraVolumeMounts is a table. Ignoring non-table value [] Error: UPGRADE FAILED: rendered manifests contain a new resource that already exists. Unable to continue with update: existing resource conflict: namespace: , name: public-nginx-ingress, existing_kind: rbac.authorization.k8s.io/v1, Kind=ClusterRole, new_kind: rbac.authorization.k8s.io/v1, Kind=ClusterRole
Я попытался пропустить часть rbac, она, кажется, уже существует и не требует повторной установки
Тогда я получаю следующий выпуск
./helm upgrade public-nginx-ingress stable/nginx-ingress --install --namespace ingress --wait -f public-nginx-ingress.yaml --set rbac.create=false coalesce.go:199: warning: destination for extraContainers is a table. Ignoring non-table value [] coalesce.go:199: warning: destination for extraVolumeMounts is a table. Ignoring non-table value [] coalesce.go:199: warning: destination for extraVolumes is a table. Ignoring non-table value [] Error: UPGRADE FAILED: cannot patch "public-nginx-ingress-controller-metrics" with kind Service: Service "public-nginx-ingress-controller-metrics" is invalid: spec.clusterIP: Invalid value: "": field is immutable && cannot patch "public-nginx-ingress-controller" with kind Service: Service "public-nginx-ingress-controller" is invalid: spec.clusterIP: Invalid value: "": field is immutable && cannot patch "public-nginx-ingress-default-backend" with kind Service: Service "public-nginx-ingress-default-backend" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Может кто-нибудь прояснить, какое здесь решение? Я вижу, что это было повторно открыто, а затем снова закрыто через 39 минут, но я не видел очевидного решения в этом потоке.

Может кто-нибудь прояснить, какое здесь решение? Я вижу, что это было повторно открыто, а затем снова закрыто через 39 минут, но я не видел очевидного решения в этом потоке.

Решения пока нет, но это многообещающее и почти готовое к реализации:

https://github.com/helm/helm/pull/7649

7649 были объединены сегодня утром.

7649 были объединены сегодня утром.

Ох, пропустил;) ну, тогда ответ на вопрос @micseydel находится в первом посте # 7649 в разделе Release Notes