<p>فشل ترقية الدفة مع spec.clusterIP: قيمة غير صالحة: "": الحقل غير قابل للتغيير</p>

لم يتم توفير معلومات كافية لإعادة إنتاج. يُرجى إخبارنا بكيفية إنشاء مخطط قابل للتكرار ، وأوامر Helm التي استخدمتها.

مرحبًا ، ها هي خطوات إعادة الإنتاج
وجود ملفين خدمة yaml على النحو التالي.

nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

بروميثيوس

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: prometheus
spec:
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      containers:
      - image: prom/prometheus
        name: prometheus
        ports:
        - containerPort: 9090
        imagePullPolicy: Always
      hostname: prometheus
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: prometheus
spec:
  selector:
    app: prometheus
  clusterIP: None
  ports:
  - name: headless
    port: 9090
    targetPort: 0

ثم ضع ملفين في helm1 / قوالب / ثم قم بتثبيت. يظهر أن خدمة بروميثيوس تستخدم ClusterIP وإصدار nginx هو 1.14.2

# helm upgrade --install test helm1
Release "test" does not exist. Installing it now.
NAME: test
LAST DEPLOYED: Tue Apr 21 20:42:55 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP    35d
prometheus   ClusterIP   None         <none>        9090/TCP   7s

# kubectl describe deployment nginx |grep Image
    Image:        nginx:1.14.2

الآن قم بتحديث قسم nginx.yaml إلى الإصدار الجديد 1.16

        image: nginx:1.16

و prometheus.yaml عن طريق تغييره إلى LoadBalancer.

spec:
  selector:
    app: prometheus
  ports:
  - name: "9090"
    port: 9090
    protocol: TCP
    targetPort: 9090
  type: LoadBalancer

الآن ضعهم كـ helm2 وقم بالترقية. ثم يمكنك أن ترى أن الترقية تطرح بعض الأخطاء ، لكن خدمة nginx تمر عبر الترقية إلى إصدار جديد ، لكن بروميثيوس لم تتم ترقيته لأنه لا يزال يستخدم Cluster IP.

# helm upgrade --install test helm2
Error: UPGRADE FAILED: cannot patch "prometheus" with kind Service: Service "prometheus" is invalid: spec.clusterIP: Invalid value: "": field is immutable

# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP    35d
prometheus   ClusterIP   None         <none>        9090/TCP   5m34s

# kubectl describe deployment nginx |grep Image
    Image:        nginx:1.16

تظهر قائمة الدفة

# helm list
NAME    NAMESPACE   REVISION    UPDATED                                 STATUS  CHART                                       APP VERSION
test    default     2           2020-04-21 20:48:20.133644429 -0700 PDT failed  

تاريخ الدفة

# helm history test
REVISION    UPDATED                     STATUS      CHART       APP VERSION DESCRIPTION                                                                                                                                               
1           Tue Apr 21 20:42:55 2020    deployed    helm-helm   1.0.0.6     Install complete                                                                                                                                          
2           Tue Apr 21 20:48:20 2020    failed      helm-helm   1.0.0.6     Upgrade "test" failed: cannot patch "prometheus" with kind Service: Service "prometheus" is invalid: spec.clusterIP: Invalid value: "": field is immutable

لدينا نفس السلوك مع v3.2.0 ، والرجوع إلى الإصدار v3.1.3 هو حلنا المؤقت

لقد حصلت على الكثير من هذا مع هجرة Helm 2 -> 3. عند محاولة ترقية الإصدارات المحولة لأول مرة ، أحصل على الكثير من هذا. هذا مخصص لمخططات Nginx Ingress و Prometheus Operator و Graylog و Jaeger حتى الآن. أنا راضٍ عن معظمهم بحذف الخدمات والسماح لـ Helm بإعادة إنشائها ولكن بالنسبة لـ Nginx Ingress هذا ليس خيارًا ...

فقط وجدت هذا https://github.com/helm/helm/issues/6378#issuecomment -557746499 الذي يشرح المشكلة في حالتي.

إغلاق كنسخة مكررة من # 6378. وجدت cablespaghetti تفسيرًا أعمق لهذا السلوك ، والذي تم وصفه بتفصيل كبير.

دعنا نعرف إذا كان هذا لا يعمل من أجلك.

GaramNick لماذا تخفيض التصنيف يصلح لك؟ هل يمكنك توضيح المزيد حول "ما" الذي تم إصلاحه من خلال خفض التصنيف؟

bacongobbler بينما أنت هنا. هل هناك أي طريقة لإصلاح هذا الموقف دون حذف الإصدار وإعادة النشر؟ لا يمكنني أن أبدو طريقة للقيام بذلك تحت الدفة 2 أو 3. أريد اختراق بيانات الإصدار الحالية ، لذلك يعتقد هيلم أن العنقود IP قد تم حذفه دائمًا وبالتالي لا يلزم وجود تصحيح.

هل جربت kubectl edit ؟

لدينا نفس المشكلة والتخفيض إلى 3.1.3 إصلاحه لنا أيضًا. أعتقد أن الأمر يتعلق بالمنطق الجديد في https://github.com/helm/helm/pull/7649/commits/d829343c1514db17bee7a90624d06cdfbffde963 مع الأخذ في الاعتبار أن هذا Create وليس تحديثًا وبالتالي محاولة تعيين فارغة IP وعدم إعادة استخدام العنوان المأهول

تجد مثيرة للاهتمام. شكرا لك على التحقيق.

jlegrone أي فرصة قد يكون لديك الوقت للنظر في هذا؟

bacongobbler يستخدم خط أنابيب CI / CD الخاص بنا Helm لتحديث تطبيقنا الذي يتضمن خدمة من النوع ClusterIP. الامر:

helm upgrade --install --force \
        --wait \
        --set image.repository="$CI_REGISTRY_IMAGE" \
        --set image.tag="$CI_COMMIT_REF_NAME-$CI_COMMIT_SHA" \
        --set image.pullPolicy=IfNotPresent \
        --namespace="$KUBE_NAMESPACE" \
        "$APP_NAME" \
        ./path/to/charts/

في الإصدار 3.2.0 ، فشل هذا الأمر مع Service "service-name" is invalid: spec.clusterIP: Invalid value: "": field is immutable

يعمل هذا بشكل جيد في الإصدار 3.1.3.

اسمحوا لي أن أعرف إذا كنت ترغب في الحصول على مزيد من المعلومات.

كذلك هنا. كان لدينا الخدمة التالية. yaml يعمل بشكل جيد مع helm2 لعدة أشهر.
بعد الترحيل ، فشل أمر helm 3.2 helm upgrade مع ظهور خطأ الحفظ على النحو الوارد أعلاه. الرجوع إلى 3.1.3 حلها.

apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.global.name }}
  namespace: {{ index .Values.global.namespace .Values.global.env }}
  labels:
     microservice: {{ .Values.global.name }}
spec:
   type: ClusterIP
   ports:
   - port: 8080
   selector:
      microservice: {{ .Values.global.name }}

لدينا نفس المشكلة وخفض التصنيف إلى 3.1.3 تم إصلاحه لنا أيضًا. أعتقد أن الأمر يتعلق بالمنطق الجديد في d829343 مع الأخذ في الاعتبار أن هذا إنشاء وليس تحديثًا وبالتالي محاولة تعيين IP فارغ وعدم إعادة استخدام المنطق المأهول

@ n1koo هل يمكن أن توضح سبب اعتقادك أن هذا هو الرمز الذي يسبب المشكلة؟ لأن هذا هو رمز التثبيت وليس الترقية ، وكذلك الكود في 3.1 هو ` create وهو يعمل.

أنا أراجع المشكلة مع حدده @ n1koo . ستتجاوز طريقة الإنشاء الاختلاف ثلاثي الاتجاهات العادي في الخدمة ، مما يؤدي إلى تعيين عنوان IP الخاص بالخدمة على "" بدلاً من القيمة التي تم ملؤها بواسطة Kubernetes. ونتيجة لذلك ، فإن البيان الذي تم إرساله إلى خادم واجهة برمجة التطبيقات يبدو أنه يعيد تعيين عنوان IP للكتلة ، وهو أمر غير قانوني في الخدمة (وبالتأكيد ليس ما يقصده المستخدم).

ما زلنا نبحث في هذا الأمر وسوف أقوم بالتحديث إذا تعلمنا المزيد.

إذن https://github.com/helm/helm/issues/6378#issuecomment -557746499 صحيح. يرجى قراءة ذلك قبل الاستمرار في هذه المشكلة. إذا تم تعيين clusterIP: "" ، فسيقوم Kubernetes بتعيين IP. في ترقية Helm التالية ، إذا كان clusterIP:"" مرة أخرى ، فسيظهر الخطأ أعلاه ، لأنه يظهر لكوبرينيتيس أنك تحاول إعادة تعيين IP. (نعم ، يقوم Kubernetes بتعديل قسم spec: للخدمة!)

عندما تتجاوز طريقة Create الفرق ثلاثي الاتجاهات ، فإنها تعين clusterIP: "" بدلاً من تعيينها على عنوان IP الذي تم تعيينه بواسطة Kubernetes.

لإعادة إنتاج:

$ helm create issue7956
$ # edit issue7956/templates/service.yaml and add `clusterIP: ""` under `spec:`
$ helm upgrade --install issue7956 issue7956
...
$ helm upgrade issue7956 issue7956
Error: UPGRADE FAILED: cannot patch "issue-issue7956" with kind Service: Service "issue-issue7956" is invalid: spec.clusterIP: Invalid value: "": field is immutable

في المرة الثانية التي تقوم فيها بتشغيل الترقية ، ستفشل.

لا يمكنني إعادة إنتاج حالة IdanAdar على master .

GaramNick لا توجد معلومات كافية حول الخدمة التي تستخدمها لنا لإعادة إنتاج الخطأ.

حالتي:
version.BuildInfo{Version:"v3.2.0", GitCommit:"e11b7ce3b12db2941e90399e874513fbd24bcb71", GitTreeState:"clean", GoVersion:"go1.13.10"}
تم اختباره أيضًا مع /
version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"}

بالنظر إلى نموذج الخدمة التالي:

apiVersion: v1
kind: Service
metadata:
  name: {{ include "app.fullname" . }}
  labels:
    {{- include "app.labels" . | nindent 4 }}
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: {{ include "app.fullname" . }}_mapping
      prefix: /{{ include "app.fullname" . }}
      host: "^{{ include "app.fullname" . }}.*"
      host_regex: true
      service: {{ include "app.fullname" . }}.{{ .Release.Namespace }}
      rewrite: ""
      timeout_ms: 60000
      bypass_auth: true
      cors:
        origins: "*"
        methods: POST, GET, OPTIONS
        headers:
        - Content-Type
        - Authorization
        - x-client-id
        - x-client-secret
        - x-client-trace-id
        - x-flow-proto
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: {{ include "app.fullname" . }}_swagger_mapping
      ambassador_id: corp
      prefix: /swagger
      host: "^{{ include "app.fullname" . }}.corp.*"
      host_regex: true
      service: {{ include "app.fullname" . }}.{{ .Release.Namespace }}
      rewrite: ""
      bypass_auth: true
      cors:
        origins: "*"
        methods: POST, GET, OPTIONS
        headers:
        - Content-Type
        - x-client-id
        - x-client-secret
        - Authorization
        - x-flow-proto
  namespace: {{ .Release.Namespace }}
spec:
  type: {{ .Values.service.type }}
  selector:
    {{- include "app.selectorLabels" . | nindent 4 }}
  ports:
  - port: {{ .Values.service.port }}
    name: http-rest-hub
    targetPort: http-rest
  - port: {{ .Values.service.healthPort }}
    name: http-health
    targetPort : http-health

مما ينتج عنه ما يلي بعد upgrade --install :

apiVersion: v1
kind: Service
metadata:
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: hub-alt-bor_mapping
      prefix: /hub-alt-bor
      host: "^hub-alt-bor.*"
      host_regex: true
      service: hub-alt-bor.brett
      rewrite: ""
      timeout_ms: 60000
      bypass_auth: true
      cors:
        origins: "*"
        methods: POST, GET, OPTIONS
        headers:
        - Content-Type
        - Authorization
        - x-client-id
        - x-client-secret
        - x-client-trace-id
        - x-flow-proto
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: hub-alt-bor_swagger_mapping
      ambassador_id: corp
      prefix: /swagger
      host: "^hub-alt-bor.corp.*"
      host_regex: true
      service: hub-alt-bor.brett
      rewrite: ""
      bypass_auth: true
      cors:
        origins: "*"
        methods: POST, GET, OPTIONS
        headers:
        - Content-Type
        - x-client-id
        - x-client-secret
        - Authorization
        - x-flow-proto
    meta.helm.sh/release-name: alt-bor
    meta.helm.sh/release-namespace: brett
  creationTimestamp: ...
  labels:
    app: hub
    app.kubernetes.io/instance: alt-bor
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: hub
    app.kubernetes.io/version: v1.6.0-rc.26
    deploy.xevo.com/stackname: bor-v0.1-test
    helm.sh/chart: hub-0.0.4
    owner: gateway
    ownerSlack: TODOunknown
  name: hub-alt-bor
  namespace: brett
  resourceVersion: ...
  selfLink: ...
  uid: ...
spec:
  clusterIP: 172.20.147.13
  ports:
  - name: http-rest-hub
    port: 80
    protocol: TCP
    targetPort: http-rest
  - name: http-health
    port: 90
    protocol: TCP
    targetPort: http-health
  selector:
    app.kubernetes.io/instance: alt-bor
    app.kubernetes.io/name: hub
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

إذا قمت بعد ذلك بتحميل هذا المخطط نفسه تمامًا مثل الإصدار 0.0.5 و upgrade --install مرة أخرى ، فسأحصل على ما يلي:
Error: UPGRADE FAILED: failed to replace object: Service "hub-alt-bor" is invalid: spec.clusterIP: Invalid value: "": field is immutable

الاختلاف الوحيد هو قيمة التصنيف helm.sh/chart الذي أصبح الآن بقيمة hub-0.0.5

هذا مانع ضخم.

GaramNick لا توجد معلومات كافية حول الخدمة التي تستخدمها لنا لإعادة إنتاج الخطأ.

technosophos ماذا تحتاج؟ يسعدني تقديم المزيد من التفاصيل!

تحديث! فشل التحديث فقط عند استخدام helm upgrade --install w / --force . أقل من مانع الآن.

أوه! موضوع مثير للاهتمام. من المفترض أن يسهل ذلك تعقب الخطأ.

مرحبًا technosophos @ bacongobbler لدينا نفس

version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"}

1. قضية
   لدينا قالب Service بدون clusterIP لكن kubernetes ستخصص clusterIP تلقائيًا:

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ .Values.image.name }}
    release: {{ .Release.Name }}
spec:
  type: ClusterIP
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.port }}
      protocol: TCP
      name: http
  selector:
    app: {{ .Values.image.name }}
    release: {{ .Release.Name }}

بعد الانتقال إلى helm 3 باستخدام helm 2to3 convert وحاول ترقية الإصدار نفسه helm3 upgrade --install --force :

failed to replace object: Service "dummy-stage" is invalid: spec.clusterIP: Invalid value: "": field is immutable

إذا كنت سأفعل الشيء نفسه بدون --force -> helm3 upgrade --install يعمل بشكل جيد بدون أخطاء.

1. قضية
   إذا أردت تغيير spec.selector.matchLabels في النشر وهو حقل غير قابل للتغيير بدون --force أحصل على خطأ:

cannot patch "dummy-stage" with kind Deployment: Deployment.apps "dummy-stage" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app.kubernetes.io/name":"web-nerf-dummy-app"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

إذا كنت سأفعل الشيء نفسه مع --force فسأحصل على خطأ:

failed to replace object: Deployment.apps "dummy-stage" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app.kubernetes.io/name":"web-nerf-dummy-app"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

هل من الممكن تنفيذ نفس السلوك لـ --force كما في helm 2 لأننا نستطيع دون أي خطأ ترقية ملف ثابت؟

apiVersion: v1
kind: Service
metadata:
  name: zipkin-proxy
  namespace: monitoring
spec:
  ports:
  - port: 9411
    targetPort: 9411
  selector:
    app: zipkin-proxy
  type: ClusterIP

---

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: zipkin-proxy
  namespace: monitoring
spec:
  replicas: {{ .Values.zipkinProxy.replicaCount }}
  template:
    metadata:
      labels:
        app: zipkin-proxy
      annotations:
        prometheus.io/scrape: 'true'
    spec:
      containers:
      - image: {{ .Values.image.repository }}/zipkin-proxy
        name: zipkin-proxy
        env:
        - name: STORAGE_TYPE
          value: stackdriver

helm upgrade -i --debug --force --namespace monitoring zipkin-proxy --values ./values.yaml.tmp .

لقد حاولت إزالة خيار القوة. حاولت مع v3.1.3 ، v3.2.0 وكذلك v3.2.1 لا تزال نفس المشكلة.

تتبع المكدس

history.go:52: [debug] getting history for release zipkin-proxy
upgrade.go:84: [debug] preparing upgrade for zipkin-proxy
upgrade.go:92: [debug] performing update for zipkin-proxy
upgrade.go:234: [debug] creating upgraded release for zipkin-proxy
client.go:163: [debug] checking 2 resources for changes
client.go:195: [debug] error updating the resource "zipkin-proxy":
         cannot patch "zipkin-proxy" with kind Service: Service "zipkin-proxy" is invalid: spec.clusterIP: Invalid value: "": field is immutable
client.go:403: [debug] Looks like there are no changes for Deployment "zipkin-proxy"
upgrade.go:293: [debug] warning: Upgrade "zipkin-proxy" failed: cannot patch "zipkin-proxy" with kind Service: Service "zipkin-proxy" is invalid: spec.clusterIP: Invalid value: "": field is immutable
Error: UPGRADE FAILED: cannot patch "zipkin-proxy" with kind Service: Service "zipkin-proxy" is invalid: spec.clusterIP: Invalid value: "": field is immutable
helm.go:75: [debug] cannot patch "zipkin-proxy" with kind Service: Service "zipkin-proxy" is invalid: spec.clusterIP: Invalid value: "": field is immutable
helm.sh/helm/v3/pkg/kube.(*Client).Update
        /home/circleci/helm.sh/helm/pkg/kube/client.go:208
helm.sh/helm/v3/pkg/action.(*Upgrade).performUpgrade
        /home/circleci/helm.sh/helm/pkg/action/upgrade.go:248
helm.sh/helm/v3/pkg/action.(*Upgrade).Run
        /home/circleci/helm.sh/helm/pkg/action/upgrade.go:93
main.newUpgradeCmd.func1
        /home/circleci/helm.sh/helm/cmd/helm/upgrade.go:137
github.com/spf13/cobra.(*Command).execute
        /go/pkg/mod/github.com/spf13/[email protected]/command.go:826
github.com/spf13/cobra.(*Command).ExecuteC
        /go/pkg/mod/github.com/spf13/[email protected]/command.go:914
github.com/spf13/cobra.(*Command).Execute
        /go/pkg/mod/github.com/spf13/[email protected]/command.go:864
main.main
        /home/circleci/helm.sh/helm/cmd/helm/helm.go:74
runtime.main
        /usr/local/go/src/runtime/proc.go:203
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1357
UPGRADE FAILED
main.newUpgradeCmd.func1
        /home/circleci/helm.sh/helm/cmd/helm/upgrade.go:139
github.com/spf13/cobra.(*Command).execute
        /go/pkg/mod/github.com/spf13/[email protected]/command.go:826
github.com/spf13/cobra.(*Command).ExecuteC
        /go/pkg/mod/github.com/spf13/[email protected]/command.go:914
github.com/spf13/cobra.(*Command).Execute
        /go/pkg/mod/github.com/spf13/[email protected]/command.go:864
main.main
        /home/circleci/helm.sh/helm/cmd/helm/helm.go:74
runtime.main
        /usr/local/go/src/runtime/proc.go:203
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1357

أواجه هذه المشكلة عندما يتغير إصدار مخطط Helm ووجود نشر حالي.

باستخدام Helm v3.2.0

أستطيع أن أؤكد أن الرجوع إلى الإصدار 3.1.2 يعمل.

@ gor181 كيف يمكننا إعادة إنتاج ذلك؟ ما كسر 3.2 لكنه عمل على 3.1؟ الرسم البياني (أو على الأقل قالب svc) والأوامر هي ما نحتاجه لنكون قادرين على معرفة ما تغير.

azarudeenaalexandrsemak - لكليكما ، العلم --force هو سبب ذلك. إذا قمت بإزالة --force ، فهل تعمل الترقية؟

technosophos حاولت دون قوة لم تنجح. التخطيط لمحاولة 3.1.2

azarudeena ، هل يمكنك تقديم مجموعة من التعليمات لإعادة values.yaml.tmp الذي لا نعرف مخرجاته ، ولا Chart.yaml.

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

bacongobbler أنا

مخطط

apiVersion: v1
description: Deploys Stackdriver Trace Zipkin Proxy
name: zipkin-proxy
version: 1.0.0

لقد وضعت نموذج yaml أعلاه ،

قيمتي yaml.tmp على النحو التالي

zipkinProxy:
  replicaCount: 1

image:
  repository: openzipkin/zipkin

أنا أحزمه كحزمة خوذة - الإصدارباستخدام نفس الشيء مع الترقية. دعني اعرف اذا هذه تعمل؟ سنقوم بالتحديث هنا بمجرد أن أحاول مع 3.1.2

يحرر

تمت المحاولة عن طريق خفض التصنيف إلى 3.1.2 و 3.1.1. لا يزال غير قادر على الحصول على هذا التصحيح.

لقد واجهت نفس المشكلة ، ولكن مع ترقية مخطط الدفة عبر مزود دفة التضاريس.
بعد أن قمت بتغيير force_update = true إلى force_update = false ، اختفى الخطأ.

أواجه هذه المشكلة عندما يتغير إصدار مخطط Helm ووجود نشر حالي.

باستخدام Helm v3.2.0

تعطيل - قوة العلم جعلها تعمل.

technosophos --force حل المشكلة مع ClusterIP عندما تقوم بالترحيل إلى helm 3 حيث لا تحاول helm 2 ترقية ClusterIP عندما يقوم helm 3 بذلك.
هيلم 3 غير قادر على حل المشكلة مع الملف غير القابل للتغيير على أنه matchLabels

يعدل Kubernetes القسم spec: لإحدى الخدمات

هل يجب اعتبار هذا عيبًا في التصميم في Kubernetes من الأساس؟ https://kubernetes.io/docs/concepts/services-networking/service/#choosing -your-own-ip-address لا تذكر هذا السلوك. كنت أتوقع أن يتم وضع القيمة المخصصة في قسم status .

(يوجد سلوك مشابه لـ .spec.nodeName لـ Pod ، لكن من غير المحتمل أن يؤثر ذلك على مستخدمي Helm.)

الإصدار 3.2.3: فشل مع --force ، فإنه يمر بدون فرض. لا يوجد ClusterIP: في قالب الرسم البياني. الذي أعتقد أن https://github.com/helm/helm/pull/8000/files كان من المفترض إصلاحه.

upgrade.go:121: [debug] preparing upgrade for eos-eve-srv-d1
upgrade.go:129: [debug] performing update for eos-eve-srv-d1
upgrade.go:308: [debug] creating upgraded release for eos-eve-srv-d1
client.go:173: [debug] checking 6 resources for changes
client.go:432: [debug] Replaced "eos-eve-srv-d1-fsnode" with kind ServiceAccount for kind ServiceAccount
client.go:432: [debug] Replaced "eos-eve-srv-d1-fsnode-imagepullsecret" with kind Secret for kind Secret
client.go:432: [debug] Replaced "eos-eve-srv-d1-fsnode-config" with kind ConfigMap for kind ConfigMap
client.go:205: [debug] error updating the resource "eos-eve-srv-d1-fsnode":
         failed to replace object: Service "eos-eve-srv-d1-fsnode" is invalid: spec.clusterIP: Invalid value: "": field is immutable
client.go:432: [debug] Replaced "eos-eve-srv-d1-fsnode" with kind Deployment for kind Deployment
client.go:432: [debug] Replaced "eos-eve-srv-d1-fsnode" with kind Ingress for kind Ingress
upgrade.go:367: [debug] warning: Upgrade "eos-eve-srv-d1" failed: failed to replace object: Service "eos-eve-srv-d1-fsnode" is invalid: spec.clusterIP: Invalid value: "": field is immutable
Error: UPGRADE FAILED: failed to replace object: Service "eos-eve-srv-d1-fsnode" is invalid: spec.clusterIP: Invalid value: "": field is immutable
helm.go:84: [debug] failed to replace object: Service "eos-eve-srv-d1-fsnode" is invalid: spec.clusterIP: Invalid value: "": field is immutable
helm.sh/helm/v3/pkg/kube.(*Client).Update
        /private/tmp/helm-20200608-50972-gq0j1j/src/helm.sh/helm/pkg/kube/client.go:218
helm.sh/helm/v3/pkg/action.(*Upgrade).performUpgrade
        /private/tmp/helm-20200608-50972-gq0j1j/src/helm.sh/helm/pkg/action/upgrade.go:322
helm.sh/helm/v3/pkg/action.(*Upgrade).Run
        /private/tmp/helm-20200608-50972-gq0j1j/src/helm.sh/helm/pkg/action/upgrade.go:130
main.newUpgradeCmd.func1
        /private/tmp/helm-20200608-50972-gq0j1j/src/helm.sh/helm/cmd/helm/upgrade.go:144
github.com/spf13/cobra.(*Command).execute
        /private/tmp/helm-20200608-50972-gq0j1j/pkg/mod/github.com/spf13/[email protected]/command.go:842
github.com/spf13/cobra.(*Command).ExecuteC
        /private/tmp/helm-20200608-50972-gq0j1j/pkg/mod/github.com/spf13/[email protected]/command.go:950
github.com/spf13/cobra.(*Command).Execute
        /private/tmp/helm-20200608-50972-gq0j1j/pkg/mod/github.com/spf13/[email protected]/command.go:887
main.main
        /private/tmp/helm-20200608-50972-gq0j1j/src/helm.sh/helm/cmd/helm/helm.go:83
runtime.main
        /usr/local/Cellar/[email protected]/1.13.12/libexec/src/runtime/proc.go:203
runtime.goexit
        /usr/local/Cellar/[email protected]/1.13.12/libexec/src/runtime/asm_amd64.s:1357
UPGRADE FAILED
main.newUpgradeCmd.func1
        /private/tmp/helm-20200608-50972-gq0j1j/src/helm.sh/helm/cmd/helm/upgrade.go:146
github.com/spf13/cobra.(*Command).execute
        /private/tmp/helm-20200608-50972-gq0j1j/pkg/mod/github.com/spf13/[email protected]/command.go:842
github.com/spf13/cobra.(*Command).ExecuteC
        /private/tmp/helm-20200608-50972-gq0j1j/pkg/mod/github.com/spf13/[email protected]/command.go:950
github.com/spf13/cobra.(*Command).Execute
        /private/tmp/helm-20200608-50972-gq0j1j/pkg/mod/github.com/spf13/[email protected]/command.go:887
main.main
        /private/tmp/helm-20200608-50972-gq0j1j/src/helm.sh/helm/cmd/helm/helm.go:83
runtime.main
        /usr/local/Cellar/[email protected]/1.13.12/libexec/src/runtime/proc.go:203
runtime.goexit
        /usr/local/Cellar/[email protected]/1.13.12/libexec/src/runtime/asm_amd64.s:1357

ألاحظ هذه المشكلة على 3.2.3 ولكن ليس على 3.2.0 . كانت القوة المعطلة أيضًا حلاً قابلاً للاستخدام.

لمعلوماتك ، القضية التي أثارها OP والتعليقات التي أثيرت هنا حول --force هي قضايا منفصلة ومنفصلة. دعنا نحاول التركيز على مشكلة OP هنا.

للتوضيح ، فإن المشكلة التي يصفها OP هي انحدار محتمل @ n1koo تم تحديده في https://github.com/helm/helm/issues/7956#issuecomment -620749552. يبدو أن هذا خطأ مشروع.

التعليقات الأخرى التي تشير إلى إزالة --force يعمل لصالحهم هي سلوك مقصود ومتوقع من وجهة نظر Kubernetes. باستخدام --force ، فإنك تطلب من Helm تقديم طلب PUT ضد Kubernetes. بشكل فعال ، أنت تطلب من Kubernetes أن تأخذ بياناتك المستهدفة (القوالب المعروضة في الرسم البياني الخاص بك من helm upgrade ) كمصدر للحقيقة واستبدال الموارد الموجودة في مجموعتك بالبيانات المعروضة. هذا مماثل لـ kubectl apply --overwrite .

في معظم الحالات ، لا تحدد القوالب الخاصة بك عنوان IP للكتلة ، مما يعني أن helm upgrade --force يطلب إزالة (أو تغيير) عنوان IP لمجموعة الخدمة. هذه عملية غير قانونية من وجهة نظر Kubernetes.

تم توثيق هذا أيضًا في # 7082.

هذا هو السبب أيضًا في إزالة --force works: يقوم Helm بإجراء عملية PATCH ، يختلف عن الحالة الحية ، ويتم دمجه في مجموعة IP في البيان المصحح ، مع الحفاظ على عنوان IP للمجموعة خلال الترقية.

إذا كنت تريد إزالة الكائن بالقوة وإعادة إنشائه مثل ما تم القيام به في Helm 2 ، فقم بإلقاء نظرة على # 7431.

أتمنى أن يوضح هذا الأشياء.

للمضي قدمًا ، دعنا نحاول التركيز على مشكلة OP هنا.

هل هناك أي حلول معروفة؟ واجهت نفس المشكلة عند محاولة ترقية https://github.com/helm/charts/tree/master/stable/rabbitmq-ha من 1.34.1 إلى 1.46.4. من الواضح --force أو رأس الرجوع إلى 3.1.3 لم يساعد، وحذف الخدمة في السؤال و helm upgrade فعلت مساعدة

EvgeniGordeev هذا سيكون الحل الخام الذي

لقد حققنا هذا أيضًا مع مخطط دخول nginxinc. نستخدم --force بشكل عام.

نظرًا لأن هذه المشكلة لا تزال مفتوحة ، فهل هناك خطط لنوع من الإصلاح لمعالجة هذا الأمر ، أم أن هذا يعتبر يعمل على أنه مصمم (من الصعب التمييز من هذا + المشكلات الأخرى التي تم فتحها بنفس السلوك)؟ قرأت تفسيرًا واحدًا مفاده أن هذه مشكلة في المخطط نفسه ويجب عدم استخدام clusterIP: "" وبدلاً من ذلك يجب حذف القيمة تمامًا.

هل هذا شيء يجب أن نطارده مع مطوري الرسوم البيانية؟

cdunford - الإصلاح المقترح للتوقف عن استخدام --force كما تم اقتراحه https://github.com/helm/helm/issues/7956#issuecomment -643432099.

يمكن أن يعالج هذا العلاقات العامة أيضًا المشكلة: # 7431 (كما اقترح في هذا التعليق) ...

لقد واجهنا هذه المشكلة للمرة N ، فنحن نستخدم علامة --force أيضًا في خط الأنابيب لدينا.

جاءت المشكلة الأصلية مع helm2 ، فهل سيتم إصلاحها أيضًا في helm2؟ تضمين التغريدة

bacongobbler لماذا تقول أن توفير "القوة" يختلف عن المشكلة إذا كان تجريدها أو تخفيض التصنيف يساعد؟

أعني ، لقد واجهت المشكلة مع Helm 3.3.4 ، https://artifacthub.io/packages/helm/bitnami/nginx chart ولم تتغير أي قيم. تم الاختبار على ثلاث غيوم مختلفة: GCP / GKE و Azure / AKS و AWS / EKS ، فشل في الثلاثة.

عملت فورًا بعد أن خفضت تصنيف Helm إلى 3.1.3 وعملت أيضًا على 3.3.4 بدون علم "--force".

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

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

tibetsam فيما يتعلق بإصلاح هذا لـ Helm 2: لا. لم نعد نقدم إصلاحات الأخطاء لبرنامج Helm 2. راجع https://helm.sh/blog/helm-v2-deprecation-timeline/ لمزيد من المعلومات.

أعتقد أنني تمكنت من إعادة إنتاج مشكلة OP مع مخطط رأس jupytherhub.
نأمل ، باستخدام الإرشادات أدناه ، أن تتمكن من إعادة إظهار المشكلة:

مهم
لا يحتوي Jupyterhub رأس الرسم البياني ل spec.clusterIP الميدانية في المواصفات خدمة لها، كما ترون (على سبيل المثال) هنا: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/c0a43af12a89d54bcd6dcb927fdcc2f623a14aca /jupyterhub/templates/hub/service.yaml#L17 -L29

أنا أستخدم خوذة ولطيفًا لإعادة إنتاج المشكلة:

➜ helm version
version.BuildInfo{Version:"v3.4.0", GitCommit:"7090a89efc8a18f3d8178bf47d2462450349a004", GitTreeState:"clean", GoVersion:"go1.14.10"}

➜ kind version
kind v0.9.0 go1.15.2 linux/amd64

➜ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T11:56:40Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.1", GitCommit:"206bcadf021e76c27513500ca24182692aabd17e", GitTreeState:"clean", BuildDate:"2020-09-14T07:30:52Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}

كيف تتكاثر

1. إنشاء مجموعة جديدة من النوع

kind create cluster

1. قم بإنشاء ملف يسمى config.yaml بالمحتوى التالي (سداسي عشري عشوائي):

proxy:
  secretToken: "3a4bbf7405dfe1096ea2eb9736c0df299299f94651fe0605cfb1c6c5700a6786"

لمعلوماتك ، أنا أتبع التعليمات الخاصة بتثبيت ملف الدفة ( رابط )

1. أضف مستودع الدفة

helm repo add jupyterhub https://jupyterhub.github.io/helm-chart/
helm repo update

1. تثبيت المخطط (مع خيار --force )

RELEASE=jhub
NAMESPACE=jhub

helm upgrade --cleanup-on-fail --force \
  --install $RELEASE jupyterhub/jupyterhub \
  --namespace $NAMESPACE \
  --create-namespace \
  --version=0.9.0 \
  --values config.yaml

1. كرر الخطوة 5

خطأ:

Error: UPGRADE FAILED: failed to replace object: PersistentVolumeClaim "hub-db-dir" is invalid: spec: Forbidden: spec is immutable after creation except resources.requests for bound claims
  core.PersistentVolumeClaimSpec{
        AccessModes:      []core.PersistentVolumeAccessMode{"ReadWriteOnce"},
        Selector:         nil,
        Resources:        core.ResourceRequirements{Requests: core.ResourceList{s"storage": {i: resource.int64Amount{value: 1073741824}, s: "1Gi", Format: "BinarySI"}}},
-       VolumeName:       "",
+       VolumeName:       "pvc-c614de5c-4749-4755-bd3a-6e603605c44e",
-       StorageClassName: nil,
+       StorageClassName: &"standard",
        VolumeMode:       &"Filesystem",
        DataSource:       nil,
  }
 && failed to replace object: Service "hub" is invalid: spec.clusterIP: Invalid value: "": field is immutable && failed to replace object: Service "proxy-api" is invalid: spec.clusterIP: Invalid value: "": field is immutable && failed to replace object: Service "proxy-public" is invalid: spec.clusterIP: Invalid value: "": field is immutable

أنا في المنصب 3.3.4 وما زالت هذه مشكلة

إصدار Helm 2.14.1 موجود إما بدون --force

الحل : التبديل إلى type.spec: NodePort إصلاح ترقية مخطط خوذة بلدي.

لدينا نفس المشكلة في الإصدار 3.4.1 مع --force flag.

bacongobbler أعلم أنك كنت تحاول بيقظة الحفاظ على مشكلة OP (منفصلة عن # 6378) من التعرض للاختطاف. اعتقدت أنه قد يساعد أولئك الذين ينشرون على مراجعة رسالة الخطأ الخاصة بهم لمعرفة ما إذا كان هذا الموضوع مخصصًا لهم أم لا:

هل رسالة الخطأ "خطأ: فشل التحديث : فشل في _ هل

هل رسالة الخطأ "خطأ: فشل الترقية: لا يمكن _patch_ ..." وأنت _ لم تستخدم _ --force في الأمر الخاص بك؟ الرجاء نشر في هذا العدد كيف قمت بإعادة إنتاجه.

تضمين التغريدة

helm3 upgrade concourse concourse/concourse -f temp.yaml  --force
Error: UPGRADE FAILED: failed to replace object: Service "concourse-web" is invalid: spec.clusterIP: Invalid value: "None": field is immutable && failed to replace object: Service "concourse-web-prometheus" is invalid: spec.clusterIP: Invalid value: "": field is immutable && failed to replace object: Service "concourse-web-worker-gateway" is invalid: spec.clusterIP: Invalid value: "": field is immutable

helm3 upgrade concourse concourse/concourse -f temp.yaml
Error: UPGRADE FAILED: cannot patch "concourse-web" with kind Service: Service "concourse-web" is invalid: spec.clusterIP: Invalid value: "None": field is immutable

أواجه نفس المشكلة على Helm 3.4.2. أقوم بتشغيل مخطط دفة يُنشئ نشرًا وحساب خدمة وخدمة. أقوم بإضافة تسمية إلى مجموعتي الحالية من الملصقات على الرسم البياني الخاص بي عند النشر ، والآن ترفض الترقية:

helm upgrade test-whale charts/app-template/ --install --values values.yaml --namespace whale --force
Error: UPGRADE FAILED: failed to replace object: Service "test-whale" is invalid: spec.clusterIP: Invalid value: "": field is immutable && failed to replace object: Deployment.apps "test-whale-canary" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"test-whale", "app-id":"302040", "environment":"test", "version":"latest"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && failed to replace object: Deployment.apps "test-whale" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"test-whale", "app-id":"302040", "environment":"test", "version":"latest"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

في الأساس ، يبدو أنه لا يمكنك إضافة تسمية بعد نشر الدفة الأولي.

يبدو الأمر فظيعًا ، لكن هل يستطيع هيلم تنفيذ قائمة بـ "الحقول الثابتة" التي ستتلقى معاملة خاصة؟

في هذه الحالة ، سيكون "الحقل غير القابل للتغيير" هو كائن الخدمة spec.clusterIP - سيعتبره Helm غير قابل للتغيير وينشئ طلب واجهة برمجة التطبيقات (API) الذي قد أ) لا يحاول استبداله ، ب) لا تحاول إزالته ج) لا تحاول تحديثه.

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

الوضع الحالي هو أن Helm غير موثوق به للغاية مع موارد الخدمة بشكل خاص لأن Helm تفترض أنه يحمل حقيقة مورد معين. هذا افتراض خاطئ يؤدي إلى المشكلة في هذه المشكلة ، حيث قد يكون المورد قد تلقى خصائص جديدة من جانب الخادم لا يعرفها Helm. ومن ثم ، يجب أن يعرف هيلم المجالات التي تحتاج إلى معاملة خاصة لكي تكون مواطنًا متوافقًا مع معايير k8s.

ملاحظة. أيضًا ، ينفذ kubectl الكثير من المنطق من جانب العميل ، والذي يسمح لـ kubectl بالأداء مع هذه المتطلبات الضمنية.

@ jbilliau-rcd

حاول ألا تستخدم القوة

pre

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

انتهى بي الأمر إلى اكتشاف ذلك. يبدو أنه يمكنك تغيير الملصقات على Deployment وعلى مواصفات البود ، ولكن ليس على محدد المطابقة ...... Kubernetes لا يحب ذلك. وهو غريب بالنسبة لي. وإلا كيف يمكنني تعديل النشر الخاص بي لاختيار البودات فقط على version "v2" أثناء ، على سبيل المثال ، نشر الكناري؟ حاليًا ، ليس لدي أي طريقة للقيام بذلك ، لذا فأنا مرتبك في هذا الجزء.

الترقية إلى إصدار رأس 3.5.0 حلت المشكلة.

الترقية إلى إصدار رأس 3.5.0 حلت المشكلة.

كيف بالضبط؟

الترقية إلى إصدار رأس 3.5.0 حلت المشكلة.

لا يزال الإصدار 3.5.0 من Helm لا يعمل.
ولكن بدون --force يعمل.

ضرب هذا في الدفة 3.5.2

حاولت إزالة --force ولكن ما زلت أحصل على نفس المشكلة.

Upgrade "gateway" failed: failed to replace object: Service "ingress"
    is invalid: spec.clusterIPs[0]: Invalid value: []string(nil): primary clusterIP
    can not be unset

تم العثور حتى الآن على حل معقول - علم --reuse-values . يعمل من أجل حالتي.

3.5.2 لا يزال لديه هذه المشكلة ، مع / بدون قيم إعادة الاستخدام

3.5.3 لديه هذا أيضًا: /