هل يمكنك تقديم مجموعة من الخطوات لإعادة إظهار المشكلة؟

bacongobbler أعتذر عن التأخير. أدركت أنه من الصعب إعادة الإنتاج محليًا باستخدام minikube نظرًا لأن لدينا كل شيء تم إعداده لـ / مع AWS EKS. في الوقت الحالي يمكنني أن أؤكد أن إصدار apiVersion الخاص بـ serviceMonitor لا يتغير ، لذا لا يبدو أنه يتعلق بـ # 6583 .

عندما أقوم بتشغيل نموذج الدفة في المرة الأولى:

# 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

بعد الترقية وبمجرد إنشاء المورد بنجاح ، أقوم بتشغيل نموذج الدفة مرة أخرى واستعادة ما يلي:

# 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 s التي فشل فيها؟

Namespaces ، وهو أمر منطقي إذا أخذنا في الاعتبار أن قائد الترتيب يحاول تطبيق البيانات ،

نعم ، تبدأ مساحات الأسماء أولاً ، لكنني كنت أتحقق مما إذا كان هذا يحدث مع أنواع معينة من الموارد أو مع

فقط للإضافة ، لاحظنا شيئًا آخر ، عند تعطيل شاشة الخدمة. عند تشغيل ترقية الدفة ، يتم إرجاع رسالة النجاح "Release" bid-mangement "تمت ترقيته. Happy Helming! إلخ. ولكن عند التحقق من خدمات موارد api ، ما زلنا نرى مراقب الخدمة الذي تم إنشاؤه.

ما لاحظناه للتو هو أن نفس الرسوم البيانية مع الخدمات الأخرى تعمل بشكل جيد وليس لدينا مشكلة. تستخدم الخدمات نفس المخططات الدقيقة مع بعض تغييرات التكوين فقط للخدمات .... غريب جدًا

تحدث المشكلة أيضًا أثناء محاولة تثبيت مخطط (على سبيل المثال ، مشغل بروميثيوس) ، إذا فشل التثبيت وحاولت تثبيته مرة أخرى ، يشكو القائد من تعارض الموارد ، وإذا حاولت إزالة المخطط ، يشكو قائلاً إنه لم يتم نشره مطلقًا .

vakaobr أشك في أنها نفس المشكلة. عندما يفشل التثبيت الأول (مع التثبيت الأول فقط) ، كما لاحظت ، لا يُصدر helm أي إصدار. ومن ثم لن يكون لدى helm أي معلومات حول إصدار للمقارنة بالموارد التي تم نشرها بالفعل وسيحاول تثبيتها لإظهار هذه الرسالة لأنه تم بالفعل تثبيت بعض الموارد. ربما يمكنك حل هذه المشكلة عن طريق استخدام --atomic مع التثبيت أو باستخدام ترقية helm --install - فرض توخي الحذر مع --force نظرًا لأنها ستحذف الموارد وتعيد إنشائها.
نحن هنا نواجه مشكلة تحدث مع المخططات المثبتة بالفعل بنجاح.

التحديث: لا يزال يحدث بعد التحديث إلى helm v3.0.0 (مستقر). @ efernandes-ANDigital، bacongobbler ، @ thomastaylor312
إذا كنت أستخدم فرق helm ، فإنه لا يظهر أي اختلافات ، وإذا استخدمت ترقية helm - install --dry-run ، فإنه يفشل مع الخطأ التالي: "خطأ: UPGRADE FAILED: البيانات المعروضة تحتوي على مورد جديد موجود بالفعل."
باستخدام helm get manifest (من الإصدار الأخير) ، يوضح هذه الموارد.
يُظهر استخدام قالب الدفة موارد الأطروحات أيضًا.
ربما يكون هذا مرتبطًا بكيفية مقارنة helm للموارد بالبيان مقابل القوالب؟
أنا أقوم بإنشاء موارد بتكرار قائمة بنطاق ، فهل يمكن أن تكون مرتبطة بهذا؟
هذه القطعة من التعليمات البرمجية ربما؟

الحل:
أظهر لنا تشغيل الترقية - التثبيت باستخدام الخيار --dry-run --debug and -v 10 أن الدفة كانت تستخدم بطريقة ما بعض المراجعات القديمة حقًا. لقد حذفنا جميع المراجعات باستثناء المراجعات الأخيرة وبدأت في العمل مرة أخرى.

هل تمكنت من حفظ دفتر الأستاذ قبل حذفها؟ كان من المفيد إعادة إظهار المشكلة إذا كانت أيدينا على علبة صلبة قابلة للتكرار.

تلقيت هذا الخطأ عند محاولة تغيير إصدار نشر واجهة برمجة التطبيقات إلى apps/v1 من extensions/v1beta1 . هيلم يرفض النشر بدون أن أقوم بإزالة النشر القديم يدويًا.

sheerun هل رأيت إجابتي فيما يتعلق بتغييرات apiVersion في هذا التعليق: https://github.com/helm/helm/issues/6646#issuecomment -547650430؟

tl؛ dr هو أنه يجب عليك إزالة الكائن القديم يدويًا من أجل "الترقية". المخططان غير متوافقين مع بعضهما البعض وبالتالي لا يمكن ترقيتهما من واحد إلى التالي بطريقة نظيفة. هل أنت على علم بأي أدوات تتعامل مع هذه الحالة؟

هذا لا يساعد حقًا لأنني ما زلت بحاجة إلى إزالة الموارد القديمة يدويًا. أتوقع أن هذه العلامة الخاصة بأمر helm update مثل --force ستزيل تلقائيًا وتضيف الموارد التي بها عدم توافق مع واجهة برمجة التطبيقات ، لكن الأمر ليس كذلك. هذا يجعل ترقيات التطبيقات في مجموعات kubernetes مرهقة للغاية. إذا لم يكن --force مسؤولاً عن ذلك ، فستكون علامة أخرى مفيدة.

إنها مشكلة مهمة جدًا في الوقت الحالي لأن kubernetes 1.16 يسقط دعم واجهات برمجة التطبيقات القديمة لذلك نحن بحاجة إلى الترقية.

أرى وجهة نظرك ... يمكننا دعم علم جديد لذلك.

إذا كانت لديك اقتراحات ، فنحن نحب العلاقات العامة مع الاختبارات والمستندات وما إلى ذلك. من المؤكد أنها تزداد أكثر وأكثر خاصة مع إصدار 1.16 ، لذلك يسعدنا النظر في المقترحات للتعامل مع هذه الحالة.

أي تحديثات على هذا؟

يجب أن يتعامل 7082 مع هذه الحالة إذا أراد شخص ما بدء العمل على هذه الميزة.

إذا كنت مضطرًا إلى استخدام هذه الحلول: https://github.com/helm/helm/issues/6646#issuecomment -546603596 ، يمكنك استخدام البرنامج النصي التالي الذي قمت بإنشائه لأتمتة هذه العملية: https: //gist.github. com / techmexdev / 5183be77abb26679e3f5d7ff99171731

خطأ مشابه

• استنساخ الخطوة
  لقد قمت بتثبيت 10 مراجعات ، عندما أقوم بتثبيت مخططات فرعية جديدة في المراجعة 11 ، فقد تم حل المشكلة.
  ثم قم بالترقية مرة أخرى بنفس المخططات ، يشتكي helm من rendered manifests contain a new resource that already exists .
• السبب
  يقارن دفة المراجعة الحالية مع المراجعة المنشورة الأولى التي لا تحتوي على موارد قمنا بتثبيتها في المراجعة الأخيرة الآن
• يصلح
  استخدم آخر مراجعة تم نشرها كـ currentRelease بدلاً من المراجعة الأولى

• حول العمل
  حذف الأسرار القديمة التي يملكها helm kubectl get secret -L owner=helm

@ jason-liew تتعلق هذه المشكلة بأمور مختلفة لا تتعلق بعدد الإصدارات. أنت تصلح خطأ آخر به خطأ مشابه. يرتبط هذا الخطأ بتغيير إصدار API للمورد.

sheerun آسف ، لقد

لدي نفس المشكلة. إن بيئة الإنتاج محظورة ولا يمكن إصلاحها.
إصدار الدفة
version.BuildInfo {الإصدار: "v3.0.2" ، GitCommit: "19e47ee3283ae98139d98460de796c1be1e3975f" ، GitTreeState: "نظيف" ، GoVersion: "go1.13.5"}
خطأ: UPGRADE FAILED: البيانات المعروضة تحتوي على مورد جديد موجود بالفعل. غير قادر على متابعة التحديث: تعارض الموارد الحالي: النوع: الخدمة ، مساحة الاسم: mynamespace ، الاسم: خدمتي

أيضًا Amazon EKS

الرجاء إضافة "تحذير! هناك خطر أن يكون لديك لبنة بدلاً من المخطط بعد التحديث" إلى https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/

رفاق العمل المذهلين. انا فخور!

اصطدمت أيضا بهذه المشكلة.

بعد الترحيل إلى الإصدار 3 باستخدام المكون الإضافي 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.

في الوقت الحالي ، نحن بحاجة إلى حل بديل نظيف أيضًا. إن حذف المورد القديم ليس حقًا خيارًا لأحمال عمل الإنتاج لدينا.

هيلم 3.0.2. لا يمكن النشر أو حتى التراجع عندما غيّر النشر السابق عدد عمليات النشر (تمت إزالته أو إضافة عملية نشر). فشل مع الخطأ:

خطأ: لم يتم العثور على نشر بالاسم "server2"

محبط للغاية.

أنا موافق. من المحبط أن تتعامل Kubernetes API مع تحديث apiVersion كتغيير جذري.

إذا كان أي شخص على دراية بحل aa داخل Kubernetes والذي يسمح للمرء بترقية الإصدارات دون الحاجة إلى إعادة إنشاء الكائن ، فنحن نحب أن نسمع عنه. نحن غير مدركين حاليًا لنقطة نهاية API المتاحة لأدوات الطرف الثالث مثل Helm من أجل "تحويل" كائن من إصدار واحد إلى الإصدار التالي.

الخيار الوحيد الذي ندركه من واجهة برمجة تطبيقات Kubernetes هو حذف الكائن وإنشائه. إنه بالتأكيد ليس مثاليًا ، لكنه الخيار الوحيد الذي ندركه في هذا الوقت.

لقد تم ذكره في https://github.com/helm/helm/issues/7219 أن الترقية من Kubernetes 1.15 إلى 1.16 نقلت الكائنات من إصدار ApiVersion مهمل (مثل extensions/v1beta1 ) إلى apps/v1 on الخلفية. إذا تمكن شخص ما من تأكيد هذا السلوك بالإضافة إلى اكتساب فهم أفضل لكيفية تحقيق Kubernetes لذلك ، فقد يمنحنا ذلك حلاً محتملاً لهذه المشكلة.

حاولت إجراء إعادة النشر من جهاز آخر (وليس الجهاز الذي سبق ونشر العدد المعدل لعمليات النشر) ، وسارت الأمور بسلاسة. يمكن أن تكون مشكلة التخزين المؤقت المحلي؟

youurayy هل تستخدم مجموعات ذات حالة؟ أم عمليات النشر؟ تدعم المجموعات ذات الحالة الخاصة فقط ترقية الموارد السلسة في K8S. عمليات النشر لا تزال تواجه مشكلة مع خدمة "خطأ في الترقية ، لا يمكن الترقية" على سبيل المثال.

واجهت نفس المشكلة هنا. لمعلوماتك ، لقد انتقلت من الإصدار 2 إلى الإصدار 3. في البداية لم يعمل لأنه كان يشتكي من أن بعض واجهات برمجة التطبيقات لم تكن صالحة. لقد قمت بترقية واجهات برمجة التطبيقات (عمليات النشر ومجموعات الحالة) ، ثم واجهت هذه المشكلة.

إصدار Helm المستخدم هو 3.0.2

نفس المشكلة هنا. لا يبدو أنه تم فتح العلاقات العامة بعد. أي شخص يعمل على هذا؟

كلا ، لا تتردد في إجراء مزيد من التحقيق. ألق نظرة على تعليقي السابق للحصول على مزيد من المعلومات حول من أين تبدأ.

bacongobbler هذا نوع من صفقة كبيرة لا؟ إذا لم أكن مخطئًا ، فلن يكون لديك خيار مع helm3 لتغيير مراجعات API الخاصة بك من v1beta1 إلى v1 بسبب التحقق من صحة OpenAPI ، لذا ألا يعني ذلك أن كل شخص يستخدم helm يجب عليه حذف عمليات النشر قبل ترقية المخطط؟

في الواقع ، قد لا يكون هذا مشكلة كبيرة كما اعتقدت ، فإن إسقاط - تتخلص القوة من جزء من المشكلة لأن ذلك يتجاوز الدمج ثلاثي الاتجاهات. أعتقد أن المشكلة الوحيدة المعلقة هي إذا كان لديك مخطط دفة 2 مثبتًا يستخدم أقدم k8s api ver ie v1beta1 ، لا يمكنك إجراء ترقية 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 من امتدادات الإصدار / v1beta1 إلى apps / v1.

هذه هي رسالة الخطأ بالضبط مع Helm3 عندما أحاول ترقية المخطط الذي تم تثبيته مع Helm3

خطأ: UPGRADE FAILED: البيانات المعروضة تحتوي على مورد جديد موجود بالفعل. غير قادر على متابعة التحديث: تعارض الموارد الحالي: النوع: DaemonSet ، مساحة الاسم: kube-system ، الاسم: omsagent

يقوم Helm2 بالترقية دون أي مشاكل.

حاولت مع جميع الإصدارات التي تم إصدارها من Helm3 ، لكن لم يحالفني الحظ.

نقدر معالجة هذا في Helm3.

@ ganga1980 ليس حلاً رائعًا ولكن الطريقة التي تعاملنا بها مع هذه المشكلة هي حذف أي موارد تشكو منها (مجموعة omsagent daemonset في حالتك) حتى تعمل. مرة أخرى ، ليس مثاليًا ، ولكنه سيعمل في النهاية بمجرد عدم وجود الموارد المتعارضة التي تستخدم إصدارات واجهة برمجة التطبيقات المهملة ، وسوف يعيد إنشاء الموارد باستخدام إصدار API المحدث. نحن على Kubernetes v1.15 و Helm 3.0.2.

لقد كان هذا مسار ترقية أفضل بالنسبة لنا لأن العديد من مخططاتنا تحتوي على أحجام ثابتة ، لذا فإن حذف المخطط من مجموعتنا وإعادة النشر لم يكن خيارًا سهلاً. لحسن الحظ ، لا توجد وحدات التخزين الدائمة في قائمة واجهات برمجة التطبيقات المتوقفة.

نفس المشكلة هنا ترقية stable/nginx-ingress قيد التشغيل:

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

انتاج:
خطأ: UPGRADE FAILED: البيانات المعروضة تحتوي على مورد جديد موجود بالفعل. غير قادر على متابعة التحديث: تعارض المورد الحالي: النوع: ClusterRole ، مساحة الاسم: ، الاسم: main-nginx-ingress

# helm version

انتاج:
version.BuildInfo {الإصدار: "v3.0.0" ، GitCommit: "e29ce2a54e96cd02ccfce88bee4f58bb6e2a28b6" ، GitTreeState: "نظيف" ، GoVersion: "go1.13.4"}

أنا موافق. من المحبط أن تتعامل Kubernetes API مع تحديث apiVersion كتغيير جذري.

إذا كان أي شخص على دراية بحل aa داخل Kubernetes والذي يسمح للمرء بترقية الإصدارات دون الحاجة إلى إعادة إنشاء الكائن ، فنحن نحب أن نسمع عنه. نحن غير مدركين حاليًا لنقطة نهاية API المتاحة لأدوات الطرف الثالث مثل Helm من أجل "تحويل" كائن من إصدار واحد إلى الإصدار التالي.

الخيار الوحيد الذي ندركه من واجهة برمجة تطبيقات Kubernetes هو حذف الكائن وإنشائه. إنه بالتأكيد ليس مثاليًا ، لكنه الخيار الوحيد الذي ندركه في هذا الوقت.

تم ذكره في # 7219 أن الترقية من Kubernetes 1.15 إلى 1.16 تعمل على ترحيل الكائنات من إصدار ApiVersion مهمل (مثل extensions/v1beta1 ) إلى apps/v1 على الواجهة الخلفية. إذا تمكن شخص ما من تأكيد هذا السلوك بالإضافة إلى اكتساب فهم أفضل لكيفية تحقيق Kubernetes لذلك ، فقد يمنحنا ذلك حلاً محتملاً لهذه المشكلة.

ما هي المشكلة الحقيقية هنا؟ من الممكن إجراء تحديث للكائن باستخدام kubectl حتى مع تغييرات API دون أي مشاكل. لا يلزم حذف الكائن (يمكن ببساطة أن يكون kubectl تطبيق / استبدال) لماذا لا يستطيع Helm فعل الشيء نفسه؟

bacongobbler أوافق على أنه من وجهة نظر k8s ، إنه التغيير المكسور بين إصدارات API. ومع ذلك ، في k8s ، يوجد تصميم للتعامل مع مثل هذه الحالة لترحيل عنصر واحد من إصدار إلى آخر.
على سبيل المثال ، في مجموعة 1.14 واحدة ، إذا تم إنشاء نشر في الإصدار "apps / v1" ، فإنه متاح أيضًا في الإصدار "apps / v1bet1" و "apps / v1bet2" و "extension / v1beta1". راجع https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/#deployment -v1-apps.
لذلك أعتقد أن تصميم gvk لـ helm3 جيد ، لكن التنفيذ يجب أن يكون أكثر تعقيدًا. لا يجب فقط استرداد كائن الإصدار القديم من مخزن إصدار الدفة ، ولكن أيضًا من بيئة التشغيل الحالية.

شكرا

أنا موافق. من المحبط أن تتعامل Kubernetes API مع تحديث apiVersion كتغيير جذري.

إذا كان أي شخص على دراية بحل aa داخل Kubernetes والذي يسمح للمرء بترقية الإصدارات دون الحاجة إلى إعادة إنشاء الكائن ، فنحن نحب أن نسمع عنه. نحن غير مدركين حاليًا لنقطة نهاية API المتاحة لأدوات الطرف الثالث مثل Helm من أجل "تحويل" كائن من إصدار واحد إلى الإصدار التالي.

الخيار الوحيد الذي ندركه من واجهة برمجة تطبيقات 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 كمثال.

هذا تحويل من تطبيقات / v1 إلى تمثيل داخلي آخر. لا يمكنك استخدام هذا للتحويل من v1beta1 إلى v1. انظر إلى الكود عن كثب.

على سبيل المثال ، في مجموعة 1.14 واحدة ، إذا تم إنشاء نشر في الإصدار "apps / v1" ، فإنه متاح أيضًا في الإصدار "apps / v1bet1" و "apps / v1bet2" و "extension / v1beta1"

تدعم مجموعات Kubernetes العديد من إصدارات API ، ولكن يتم التعامل معها ككائنات منفصلة منفصلة. المخططات الداخلية مختلفة تمامًا. لا توجد واجهة برمجة تطبيقات "تحويل من v1beta1 إلى v1" نعلم بوجودها في الوقت الحالي.

لا أعرف ما إذا كان هذا قد تم تعويمه من قبل ، ولكن ربما توجد طريقة لإخبار Helm بـ "اعتماد" الموارد إذا كانت موجودة بالفعل - على سبيل المثال ، في حالة وجود مساحة اسم ، سيتم تصحيحها ببيان يوفره المستخدم و من المفهوم أن يتولى هيلم إدارته من تلك النقطة.

انظر # 2730

@ bacongobbler شكرًا على إجاباتك ومساعدتك هنا. لدي نفس المشكلة مع إصدار api ، ولكن في المجموعة نفسها ، فإن النشر لدينا - apiVersion: apps / v1
يحتوي الإصدار الجديد من المخطط أيضًا على: apiVersion: apps / v1
ولكن في البيانات الوصفية / الإصدار الخاص بـ Helm 3 ، لدينا ما يلي:
الإصدار: ملحقات / v1beta1
النوع: النشر

ليس من الملائم حقًا أن تحتاج إلى إعادة تثبيت عبء عمل الإنتاج فقط لإصلاح بيانات Helm الوصفية ، نظرًا لأن النشر الحقيقي له إصدار API صحيح. أي اقتراحات هنا؟ أفكر في تعديل البيانات الوصفية يدويًا.

أي اقتراحات هنا؟

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

تضمين التغريدة
سأوضح كيف يمكن لـ kubernetes استخدام العديد من إصدارات واجهة برمجة التطبيقات من التصميم والتعليمات البرمجية ووقت التشغيل.

1. تصميم الوثيقة
   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
   يمكنك أن ترى كائنًا واحدًا (من خلال معرفه المعرِّف) يمكن استرداده بواسطة إصدارات متعددة من واجهة برمجة التطبيقات.

مهلا،

أواجه نفس المشكلة. مشكلتي تتعلق بمجموعة ذات حالة موجودة مسبقًا. سيكون موضع تقدير أي نصيحة.

شكرا،
ريتشارد

دعونا نفتح المناقشات:
https://github.com/helm/helm/pull/7575

مرحبا،

أواجه نفس المشكلة التي أعتقد أنني قمت بالترقية من helm 2.14.1 إلى الأحدث ، نحصل على الخطأ كما هو مذكور أعلاه: البيانات المقدمة تحتوي على مورد موجود بالفعل.

شكرا
هاني

إليك اختراق قذر نستخدمه عندما يكون هناك مورد ، مثل 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 موجودة في