Helm: Helm 3 - ترقية nginx - spec.clusterIP: قيمة غير صالحة: "": الحقل غير قابل للتغيير

من المحتمل أن يكون هذا مرتبطًا بتغيير حديث في Helm 3 حيث يستخدم الآن استراتيجية تصحيح دمج ثلاثية مشابهة لـ kubectl. انظر # 6124

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

بالتأكيد!

لقد قمت بإنشاء مجموعة AKS.

أقوم بإنشاء IP عام في مجموعة موارد MC_ *.

لقد قمت بتخزين عنوان IP لهذا IP العام في $ ip.

ثم نفذ هذا الأمر بشكل أساسي مرتين:

./helm ترقية - تثبيت
- ضبط rbac.create = خطأ
- ضبط وحدة تحكم. ReplicaCount = 2
- ضبط controller.service.loadBalancerIP = $ ip
- انتظار دخول مستقر / دخول nginx

هذا مشابه لما يتم عمله في https://docs.microsoft.com/en-us/azure/aks/ingress-static-ip.

الفرق هو أنني أقوم بترقية الدفة - التثبيت مرتين. والغرض من ذلك هو الحصول على سطر أوامر واحد (غير مشروط) في CI / CD الخاص بي.

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

هل كان ذلك كافيا للتكاثر؟ يمكنني تقديم برنامج نصي باش إذا كان يساعد.

معذرةً ، في هيلم سوميت الاتحاد الأوروبي لهذا الأسبوع ، لذا لم يكن لدي وقت للرد حتى الآن.

آه ... لا تقلق. استمتع بالقمة!

أنا أيضا أواجه هذه المشكلة

$ helm version --short
v3.0.0-beta.3+g5cb923e

يتم تثبيت مخطط nginx-ingress بشكل جيد عند التشغيل الأول ، ولكن عند الترقية ...

$ helm upgrade --install first-chart stable/nginx-ingress --namespace infra
client.go:357: Cannot patch Service: "first-chart-nginx-ingress-controller" (Service "first-chart-nginx-ingress-controller" is invalid: spec.clusterIP: Invalid value: "": field is immutable)
client.go:376: Use --force to force recreation of the resource
client.go:357: Cannot patch Service: "first-chart-nginx-ingress-default-backend" (Service "first-chart-nginx-ingress-default-backend" is invalid: spec.clusterIP: Invalid value: "": field is immutable)
client.go:376: Use --force to force recreation of the resource
Error: UPGRADE FAILED: Service "first-chart-nginx-ingress-controller" is invalid: spec.clusterIP: Invalid value: "": field is immutable && Service "first-chart-nginx-ingress-default-backend" is invalid: spec.clusterIP: Invalid value: "": field is immutable

$ helm ls -n infra
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART               
first-chart     infra           1               2019-09-17 16:15:25.513997106 -0500 CDT deployed        nginx-ingress-1.20.0
first-chart     infra           2               2019-09-17 16:15:30.845249671 -0500 CDT failed          nginx-ingress-1.20.0

أعتقد أن هذه مشكلة في مخطط nginx-ingress وليس helm3. بشكل افتراضي ، سيحاول المخطط دائمًا تجاوز controller.service.clusterIP = "" و defaultBackend.service.clusterIP = "" ما لم تقم بتعيين controller.service.omitClusterIP=true و defaultBackend.service.omitClusterIP=true .

ارتباط بالمصادر:
https://github.com/helm/charts/blob/master/stable/nginx-ingress/values.yaml#L321
https://github.com/helm/charts/blob/master/stable/nginx-ingress/templates/controller-service.yaml#L22

الحل:

$ helm upgrade --install ingress-test stable/nginx-ingress --set controller.service.omitClusterIP=true --set defaultBackend.service.omitClusterIP=true

لقد حاولت القيام بذلك ، ولكن ما زلت أتلقى نفس الخطأ

helm upgrade --install ingx stable/nginx-ingress -f ingx-values.yaml                                             1 ↵
client.go:357: Cannot patch Service: "ingx-nginx-ingress-controller" (Service "ingx-nginx-ingress-controller" is invalid: spec.clusterIP: Invalid value: "": field is immutable)
client.go:376: Use --force to force recreation of the resource
client.go:357: Cannot patch Service: "ingx-nginx-ingress-default-backend" (Service "ingx-nginx-ingress-default-backend" is invalid: spec.clusterIP: Invalid value: "": field is immutable)
client.go:376: Use --force to force recreation of the resource
Error: UPGRADE FAILED: Service "ingx-nginx-ingress-controller" is invalid: spec.clusterIP: Invalid value: "": field is immutable && Service "ingx-nginx-ingress-default-backend" is invalid: spec.clusterIP: Invalid value: "": field is immutable

قيم- ingx.yaml

rbac:
  create: true
controller:
  service:
    externalTrafficPolicy: Local
    omitClusterIP: true
  autoscaling:
    enabled: true
    minReplicas: 2
    maxReplicas: 100
    targetCPUUtilizationPercentage: "70"
    targetMemoryUtilizationPercentage: "70"
defaultBackend:
  service:
    omitClusterIP: true

كما ترى أدناه ، لا يحتوي القالب على الكتلة IP بداخله

helm template ingx stabil / nginx-ingress -f ingx-values.yaml

---
# Source: nginx-ingress/templates/controller-serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress
---
# Source: nginx-ingress/templates/default-backend-serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress-backend
---
# Source: nginx-ingress/templates/clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - update
      - watch
  - apiGroups:
      - extensions
      - "networking.k8s.io" # k8s 1.14+
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
  - apiGroups:
      - extensions
      - "networking.k8s.io" # k8s 1.14+
    resources:
      - ingresses/status
    verbs:
      - update
---
# Source: nginx-ingress/templates/clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ingx-nginx-ingress
subjects:
  - kind: ServiceAccount
    name: ingx-nginx-ingress
    namespace: default
---
# Source: nginx-ingress/templates/controller-role.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress
rules:
  - apiGroups:
      - ""
    resources:
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - endpoints
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - update
      - watch
  - apiGroups:
      - extensions
      - "networking.k8s.io" # k8s 1.14+
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - extensions
      - "networking.k8s.io" # k8s 1.14+
    resources:
      - ingresses/status
    verbs:
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      - ingress-controller-leader-nginx
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - create
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
---
# Source: nginx-ingress/templates/controller-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ingx-nginx-ingress
subjects:
  - kind: ServiceAccount
    name: ingx-nginx-ingress
    namespace: default
---
# Source: nginx-ingress/templates/controller-service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    component: "controller"
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress-controller
spec:
  externalTrafficPolicy: "Local"
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: http
    - name: https
      port: 443
      protocol: TCP
      targetPort: https
  selector:
    app: nginx-ingress
    component: "controller"
    release: ingx
  type: "LoadBalancer"
---
# Source: nginx-ingress/templates/default-backend-service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    component: "default-backend"
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress-default-backend
spec:
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: http
  selector:
    app: nginx-ingress
    component: "default-backend"
    release: ingx
  type: "ClusterIP"
---
# Source: nginx-ingress/templates/controller-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    component: "controller"
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress-controller
spec:
  replicas: 1
  revisionHistoryLimit: 10
  strategy:
    {}
  minReadySeconds: 0
  template:
    metadata:
      labels:
        app: nginx-ingress
        component: "controller"
        release: ingx
    spec:
      dnsPolicy: ClusterFirst
      containers:
        - name: nginx-ingress-controller
          image: "quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.25.1"
          imagePullPolicy: "IfNotPresent"
          args:
            - /nginx-ingress-controller
            - --default-backend-service=default/ingx-nginx-ingress-default-backend
            - --election-id=ingress-controller-leader
            - --ingress-class=nginx
            - --configmap=default/ingx-nginx-ingress-controller
          securityContext:
            capabilities:
                drop:
                - ALL
                add:
                - NET_BIND_SERVICE
            runAsUser: 33
            allowPrivilegeEscalation: true
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          livenessProbe:
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            timeoutSeconds: 1
            successThreshold: 1
            failureThreshold: 3
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
            - name: https
              containerPort: 443
              protocol: TCP
          readinessProbe:
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            timeoutSeconds: 1
            successThreshold: 1
            failureThreshold: 3
          resources:
            {}
      hostNetwork: false
      serviceAccountName: ingx-nginx-ingress
      terminationGracePeriodSeconds: 60
---
# Source: nginx-ingress/templates/default-backend-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    component: "default-backend"
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress-default-backend
spec:
  replicas: 1
  revisionHistoryLimit: 10
  template:
    metadata:
      labels:
        app: nginx-ingress
        component: "default-backend"
        release: ingx
    spec:
      containers:
        - name: nginx-ingress-default-backend
          image: "k8s.gcr.io/defaultbackend-amd64:1.5"
          imagePullPolicy: "IfNotPresent"
          args:
          securityContext:
            runAsUser: 65534
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
              scheme: HTTP
            initialDelaySeconds: 30
            periodSeconds: 10
            timeoutSeconds: 5
            successThreshold: 1
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
              scheme: HTTP
            initialDelaySeconds: 0
            periodSeconds: 5
            timeoutSeconds: 5
            successThreshold: 1
            failureThreshold: 6
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP
          resources:
            {}
      serviceAccountName: ingx-nginx-ingress-backend
      terminationGracePeriodSeconds: 60
---
# Source: nginx-ingress/templates/controller-hpa.yaml
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    component: "controller"
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress-controller
spec:
  scaleTargetRef:
    apiVersion: apps/v1beta1
    kind: Deployment
    name: ingx-nginx-ingress-controller
  minReplicas: 2
  maxReplicas: 100
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 70
    - type: Resource
      resource:
        name: memory
        targetAverageUtilization: 70

أظن أنه حدث لأنني قمت بنشره في الأصل بدون معلمات omitClusterIP ، ويحاول helm v3 إجراء دمج ثلاثي الاتجاه مع البيان الأصلي ، والذي يحتوي على clusterIP: "" بداخله

helm get manifest ingx --revision 1 | grep "clusterIP"
  clusterIP: ""
  clusterIP: ""

لقد تمكنت من إصلاحه عن طريق حذف المخطط الحالي أولاً ، وإعادة إنشائه بخيارات omitClusterIP . خلاصة القول ، لن يعمل الحل البديل المقترح من bambash إلا إذا قمت بتثبيت مخطط مع تعيين هذه الخيارات على "صحيح" من البداية

$ helm upgrade --install ingress-test stable/nginx-ingress --set controller.service.omitClusterIP=true --set defaultBackend.service.omitClusterIP=true

سيكون رائعًا إذا كانت هناك طريقة في دفة v3 لتخطي الدمج مع البيان الحالي

آسف ، كان يجب أن أحدد أن هذه القيم تحتاج إلى تعيين عند تثبيت الإصدار في البداية. قد يكون تحديث إصدار موجود أصعب ...

أنا أواجه هذه المشكلة مع metric-server-2.8.8 ، والذي لا يحتوي على أي مجموعة IP في قيمها ، وبعض المخططات الأخرى ، مع helm v3.0.0-rc.2. اي نصيحه؟ لست متأكدًا من كيفية المتابعة.

يبدو أن مشكلتي مع helmfile v0.95.0. سأتابعها هناك :)

لدي نفس المشكلة ، حتى بدون تعيين نوع الخدمة أو عنوان IP للمجموعة باستخدام helm v3.0.0-rc.2 إذا استخدمت الخيار --force مع أمر helm update --install. بدون - القوة تعمل بشكل جيد

johannges ، كنت على وشك نشر نفس الشيء. : +1:

يبدو أن إعداد omitClusterIP: true يعمل مع خدمات الخلفية الافتراضية ووحدة التحكم ولكن ليس مع المقاييس .

أعتقد أن هذه مشكلة تتعلق بالخيار --force أثناء الترقية.
تحاول Helm إعادة إنشاء الخدمة ولكنها أيضًا تحل محل spec.clusterIP لذا فإنها تتسبب في حدوث خطأ.
يمكنني تأكيد ذلك باستخدام الرسم البياني المخصص الخاص بي.
Error: UPGRADE FAILED: failed to replace object: Service "litespeed" is invalid: spec.clusterIP: Invalid value: "": field is immutable

في الواقع لقد كان خطأ من ناحيتي ، إهمال تعريف الكتلة IP عند تهيئة الخدمة (أو المخطط) يعمل بشكل جيد

كنت أواجه هذا الخطأ أيضًا لإصدارات الرسم البياني _kafka_ و _redis_ التي تم نشرها حاليًا. أدت إزالة --force حل هذا بالفعل.

يظهر لي الآن خطأ جديد من إصدار _redis_:
Error: UPGRADE FAILED: release redis failed, and has been rolled back due to atomic being set: cannot patch "redis-master" with kind StatefulSet: StatefulSet.apps "redis-master" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbidden

تم الاتفاق مع bacongobbler على أن هذا يبدو مرتبطًا بإستراتيجية تصحيح الدمج ثلاثية الاتجاهات Helm v3 والتي من المحتمل أن تؤدي إلى تمرير الحقول (حتى مع نفس القيم كما في السابق) إلى التحديث / التصحيح الذي يعتبره Kubernetes غير قابل للتغيير / غير قابل للتغيير بعد الإنشاء الأول.

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

تحرير: الخطأ بأكمله: ("nginx-ingress-singleton-controller" هو اسم الإصدار الذي قمت بتعيينه. ليس له معنى محدد)

Error: cannot patch "nginx-ingress-singleton-controller" with kind Service: Service "nginx-ingress-singleton-controller" is invalid: spec.clusterIP: Invalid value:
"": field is immutable && cannot patch "nginx-ingress-singleton-default-backend" with kind Service: Service "nginx-ingress-singleton-default-backend" is invalid: sp
ec.clusterIP: Invalid value: "": field is immutable

  on .terraform/modules/app_dev/nginx-ingress.tf line 1, in resource "helm_release" "nginx_ingress":
   1: resource "helm_release" "nginx_ingress" {

@ zen4ever سمّر المشكلة في https://github.com/helm/helm/issues/6378#issuecomment -532766512. سأحاول شرحه بمزيد من التفصيل ....

كما أشار آخرون ، تظهر المشكلة عندما يحدد الرسم البياني الكتلة IP بسلسلة فارغة. عند تثبيت الخدمة ، يملأ Kubernetes هذا الحقل بمجموعة IP التي تم تعيينها للخدمة.

عندما يتم استدعاء helm upgrade ، طلب الرسم البياني إزالة clusterIP ، ولهذا السبب كانت رسالة الخطأ spec.clusterIP: Invalid value: "": field is immutable .

يحدث هذا بسبب السلوك التالي:

1. عند التثبيت ، حدد الرسم البياني أنه يريد أن يكون clusterIP سلسلة فارغة
2. عيَّنت Kubernetes الخدمة تلقائيًا clusterIP . سنستخدم 172.17.0.1 لهذا المثال
3. في helm upgrade ، يريد المخطط أن يكون clusterIP سلسلة فارغة (أو في حالة @ zen4ever أعلاه ، تم حذفها)

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

في Helm 2 ، تجاهل الحالة الحية ، لذلك لم يلاحظ أي تغيير (الحالة القديمة: clusterIP: "" إلى الحالة الجديدة: clusterIP: "" ) ، ولم يتم إنشاء أي تصحيح ، متجاوزًا هذا السلوك.

توصيتي هي تغيير إخراج النموذج. إذا لم يتم تقديم clusterIP كقيمة ، فلا تقم بتعيين القيمة على سلسلة فارغة ... احذف الحقل تمامًا.

على سبيل المثال في حالة stable/nginx-ingress :

spec:
{{- if not .Values.controller.service.omitClusterIP }}
  clusterIP: "{{ .Values.controller.service.clusterIP }}"
{{- end }}

يجب التغيير إلى:

spec:
{{- if not .Values.controller.service.omitClusterIP }}
  {{ with .Values.controller.service.clusterIP }}clusterIP: {{ quote . }}{{ end }}
{{- end }}

هذا أيضًا هو سبب عمل --set controller.service.omitClusterIP=true في هذه الحالة.

TL ؛ DR لا تفعل ذلك في قوالب الخدمة الخاصة بك:

clusterIP: ""

خلاف ذلك ، سيحاول Helm تغيير مجموعة IP للخدمة من عنوان IP تم إنشاؤه تلقائيًا إلى سلسلة فارغة ، ومن هنا تظهر رسالة الخطأ.

أتمنى أن يساعدك هذا!

كحل مؤقت إذا كنت تحاول تشغيل هذا في الوقت الحالي أثناء حل هذه المشكلة ، وجدت أنه إذا قمت بما يلي ، فقد تمكنت من إجراء تحديث:

1. احصل على قيم العنقودية IP لوحدة التحكم والخلفية الافتراضية عبر:
   kubectl get svc | grep ingress
2. أضف عمليات الكتابة التالية إلى ملف قيم الدفة الموجود لديك:
   controller: service: clusterIP: <cluster-ip-address-for-controller> defaultBackend: service: clusterIP: <cluster-ip-address-for-default-backend>
3. قم بإجراء التحديث.

لقد اختبرت هذا لمجموعة أقوم بتشغيلها ولم تتطلب أي استجمام.

هذا يعمل أيضا. دعوة جيدةtreacher. تعيين نفس القيمة عبر --set أو في ملف القيم الخاص بك لا ينتج عنه تصحيح ، لأن الترقية لا تريد تغيير قيمة clusterIP .

الإغلاق كعمل متعمد وفقًا لسلوك تصحيح الدمج ثلاثي الاتجاهات الموضح أعلاه. عنصر العمل لهذه المخططات لاتباع التوصية المقدمة أعلاه في https://github.com/helm/helm/issues/6378#issuecomment-557746499. لا يوجد شيء تفعله هنا في نهاية هيلم. :)

https://github.com/helm/charts/pull/19146/ تم إنشاء @ bacongobbler

@ zen4ever سمّر المشكلة في # 6378 (تعليق) . سأحاول شرحه بمزيد من التفصيل ....

كما أشار آخرون ، تظهر المشكلة عندما يحدد الرسم البياني الكتلة IP بسلسلة فارغة. عند تثبيت الخدمة ، يملأ Kubernetes هذا الحقل بمجموعة IP التي تم تعيينها للخدمة.

عندما يتم استدعاء helm upgrade ، طلب الرسم البياني إزالة clusterIP ، ولهذا السبب كانت رسالة الخطأ spec.clusterIP: Invalid value: "": field is immutable .

يحدث هذا بسبب السلوك التالي:

1. عند التثبيت ، حدد الرسم البياني أنه يريد أن يكون clusterIP سلسلة فارغة
2. عيَّنت Kubernetes الخدمة تلقائيًا clusterIP . سنستخدم 172.17.0.1 لهذا المثال
3. في helm upgrade ، يريد المخطط أن يكون clusterIP سلسلة فارغة (أو في حالة @ zen4ever أعلاه ، تم حذفها)

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

في Helm 2 ، تجاهل الحالة الحية ، لذلك لم يلاحظ أي تغيير (الحالة القديمة: clusterIP: "" إلى الحالة الجديدة: clusterIP: "" ) ، ولم يتم إنشاء أي تصحيح ، متجاوزًا هذا السلوك.

توصيتي هي تغيير إخراج النموذج. إذا لم يتم تقديم clusterIP كقيمة ، فلا تقم بتعيين القيمة على سلسلة فارغة ... احذف الحقل تمامًا.

على سبيل المثال في حالة stable/nginx-ingress :

spec:
{{- if not .Values.controller.service.omitClusterIP }}
  clusterIP: "{{ .Values.controller.service.clusterIP }}"
{{- end }}

يجب التغيير إلى:

spec:
{{- if not .Values.controller.service.omitClusterIP }}
  {{ with .Values.controller.service.clusterIP }}clusterIP: {{ quote . }}{{ end }}
{{- end }}

مرحبًا bacongobbler ، أعتقد أنه إذا لم يتم تقديم أي قيمة ، clusterIP: "" ... الأفضل أن تكون القيمة clusterIP: "" تم التعليق عليها بالكامل في ملف القيم. هذا يحذفها من البيانات المعروضة عند ضبطها ويجب أن تنقذ الصداع في المستقبل. ومع ذلك ، إذا كان استخدام helm3 وحالة الدفة الحالية لديه clusterIP: "" مجموعة ، يحتاج المرء إلى ترميز ثابت لعناوين المجموعة IP في ملفات القيم.

هذا أيضًا هو سبب عمل --set controller.service.omitClusterIP=true في هذه الحالة.

TL ؛ DR لا تفعل ذلك في قوالب الخدمة الخاصة بك:

clusterIP: ""

خلاف ذلك ، سيحاول Helm تغيير مجموعة IP للخدمة من عنوان IP تم إنشاؤه تلقائيًا إلى سلسلة فارغة ، ومن هنا تظهر رسالة الخطأ.

أتمنى أن يساعدك هذا!

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

Error: UPGRADE FAILED: failed to replace object: Service "dummy" is invalid: spec.clusterIP: Invalid value: "": field is immutable

ليس لدينا spec.clusterIP: في قالب الدفة الخاص بنا ولكننا حصلنا على هذا الخطأ بعد ترحيل الإصدار عبر helm 2to3

نموذج الخدمة:

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ .Values.image.name }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "-" }}
    cluster: {{ default "unknown" .Values.cluster }}
    region: {{ default "unknown" .Values.region }}
    datacenter: {{ default "unknown" .Values.datacenter }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  type: ClusterIP
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.port }}
      protocol: TCP
      name: http
  selector:
    app: {{ .Values.image.name }}
    release: {{ .Release.Name }}

نفس المشكلة هنا. الشيء هو أننا لم نتطرق إلى الخدمة. إنه Ingress الذي تم تغييره قبل الترقية.

إنه يؤثر على الموارد ذات الحقل غير القابل للتغيير إذا حذفت --force flag من helm upgrade --install ولا تلمس الحقل الثابت ، فكل شيء يعمل بشكل جيد. ولكن إذا كنت تريد الاستغراق في الاستغناء عن الموارد ؟؟؟ أنت بحاجة إلى إعادة إنشاء الموارد لكن الدفة 3 لن تقوم بترقية الموارد ....
تضمين التغريدة

حاول تحديث hpa مع الإصدار الجديد من helm 3:
Error: UPGRADE FAILED: rendered manifests contain a new resource that already exists. Unable to continue with update: existing resource conflict: kind: HorizontalPodAutoscaler, namespace: stage, name: dummy-stage

تم تحديث تعليق bacongobbler و @ kritcher722 الإبهام إذا كنت ترغب في إزالة الإبهام ، ولكن إذا كنت لا تزال في خلاف ، يرجى توضيح سبب وجود clusterIP: "" في البيانات المقدمة فكرة جيدة.

يبدو أن Microsoft هي معلم المشروع. أنا أرى الأسلوب. :)

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

antonakv ما طريقة بداية العام :)
أعتقد بشكل عام أننا نلعب بالنار عندما نوفر CLASSIP كقيمة قابلة للتكوين في الرسم البياني ، ولا يمكننا إلقاء اللوم تمامًا على أداة / شخص / علاقات عامة على وجه الخصوص.
إذا احتاجت الكتلة IP إلى أن تكون قيمة قابلة للتكوين ، فلا يجب أن تكون افتراضيًا في القالب المعروض ، فهذه هي فكرة تعليقي في ملفات القيم وفقًا لـ https://github.com/helm/charts/blob/270172836fd8cf56d787cf7d04d938856de0c794/stable /nginx-ingress/values.yaml#L236

هذا ، إذا لم أكن مخطئًا ، يجب أن يمنع حدوث صداع مستقبلي لأولئك الذين يقومون بتثبيت الرسم البياني اعتبارًا من هذا التغيير. لكن بالنسبة لأولئك منا (وأنا منهم) الذين تثبيته قبل، ثم هاجر إلى helm3، وأخشى hardcording القيم clusterIP الحالية في ملفات قيمنا أو إلغاء تثبيت وإعادة تثبيت الرسم البياني (أسباب التوقف!) هي الخيارات الوحيدة I نرى.

الآراء تخصني ، ولا أتقاضى أجرًا مقابل العمل على دفة القيادة ، بل مجرد مستخدم نهائي مثلك. أولئك الذين يتقاضون رواتبهم مقابل العمل بدوام كامل قد يكونون قادرين على تقديم المزيد من البصيرة.

عام جديد سعيد ونتمنى لك التوفيق! لا تتخلى عن دفة القيادة ، يمكننا معًا تحسينها.

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

Error: UPGRADE FAILED: failed to replace object: Service "dummy" is invalid: spec.clusterIP: Invalid value: "": field is immutable

ليس لدينا spec.clusterIP: في قالب الدفة الخاص بنا ولكننا حصلنا على هذا الخطأ بعد ترحيل الإصدار عبر helm 2to3

نموذج الخدمة:

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ .Values.image.name }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "-" }}
    cluster: {{ default "unknown" .Values.cluster }}
    region: {{ default "unknown" .Values.region }}
    datacenter: {{ default "unknown" .Values.datacenter }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  type: ClusterIP
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.port }}
      protocol: TCP
      name: http
  selector:
    app: {{ .Values.image.name }}
    release: {{ .Release.Name }}

لدينا نفس المشكلة. لم نحدد clusterIP على الإطلاق في مخططنا وهو غير موجود في القالب النهائي. ومع ذلك ، ما زلنا نحصل على نفس الخطأ وفقط بعلامة --force .

نحن نواجه نفس المشكلة:

apiVersion: v1
kind: Service
{{ include "mde.metadata" $ }}
spec:
  ports:
  - name: {{ include "mde.portName" $ | quote }}
    port: {{ include "mde.port" $ }}
    protocol: TCP
    targetPort: {{ include "mde.port" $ }}
  selector:
    app: {{ include "mde.name" $ }}
  sessionAffinity: None
  type: ClusterIP

spec.clusterIP ليس جزءًا من قالب الخدمة ، ولكن مع Helm 3.0.2 ومكالمة helm upgrade ... --force --install ، نشاهد أيضًا:

خطأ: UPGRADE FAILED: فشل في استبدال الكائن: الخدمة "وهمية" غير صالحة: spec.clusterIP: قيمة غير صالحة: "": الحقل غير قابل للتغيير

يرجى إعادة الفتح.

@ tomcruise81 يرجى الاطلاع على https://github.com/helm/helm/issues/7350 لمعرفة الموضوع على --force . ينتج عن هذا الخطأ نفسه ، ولكنه يرجع إلى كيفية عمل kubectl replace . إنها مشكلة منفصلة عما هو موصوف هنا ، والذي يتعلق بمجموعات الخدمات واستراتيجية التصحيح الدمج ثلاثي الاتجاهات ( helm upgrade بدون علامة --force ).

bacongobbler - شكرًا على الرد السريع والتوضيح. انظر الى:

https://github.com/helm/helm/blob/a963736f6675e972448bf7a5fd141628fd0ae4df/pkg/kube/client.go#L405 -L411

التي تستخدم https://github.com/kubernetes/cli-runtime/blob/master/pkg/resource/helper.go#L155 -L181 ، لا يبدو أن الاتصال بـ helper.Replace يفعل نفس الشيء مثل kubectl replace -f ... --force (لاحظ - force في النهاية).

أظن أن هذا هو المكان الذي يوجد فيه الكثير من الارتباك.

أعلم أن توقعي لـ helm upgrade ... --force وهو يستخدم إستراتيجية بديلة هو أنه سيفعل الشيء نفسه مثل kubectl replace -f ... --force .

مرحبًا bacongobbler ، لقد واجهنا نفس المشكلة أثناء ترحيل إصدار helm v2 إلى helm v3. نحن نستخدم type: ClusterIP في الخدمة ولكن حذف ClusterIP على الإطلاق ونحصل على:
Error: UPGRADE FAILED: failed to replace object: Service "dummy" is invalid: spec.clusterIP: Invalid value: "": field is immutable
ليس لدينا spec.clusterIP: في قالب الدفة الخاص بنا ولكننا حصلنا على هذا الخطأ بعد ترحيل الإصدار عبر helm 2to3
نموذج الخدمة:

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ .Values.image.name }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "-" }}
    cluster: {{ default "unknown" .Values.cluster }}
    region: {{ default "unknown" .Values.region }}
    datacenter: {{ default "unknown" .Values.datacenter }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  type: ClusterIP
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.port }}
      protocol: TCP
      name: http
  selector:
    app: {{ .Values.image.name }}
    release: {{ .Release.Name }}

لدينا نفس المشكلة. لم نحدد clusterIP على الإطلاق في مخططنا وهو غير موجود في القالب النهائي. ومع ذلك ، ما زلنا نحصل على نفس الخطأ وفقط بعلامة --force .

لقد تحققت أيضًا من عدم وجود clusterIP في بيان الإصدار:

$ helm get manifest paywall-api-ee | grep clusterIP
$

نفس الشيء هنا - نحن لا نحدد ClusterIP أي مكان ولكننا ما زلنا نرى الخطأ

العبث مع هذا أكثر من ذلك ، لقد لاحظت ما يلي:

• helm upgrade ... --force --install - النتائج في _الخدمة "وهمية" غير صالحة: spec.clusterIP : قيمة غير صالحة: "": الحقل
• helm template ... | kubectl apply -f - - يعمل
• helm template ... | kubectl replace -f - - النتائج في _الخدمة "وهمية" غير صالحة: spec.clusterIP : قيمة غير صالحة: "": الحقل
• helm template ... | kubectl replace --force -f - - يعمل

إصدار kubectl - 1.14.6
إصدار الدفة - 3.0.2

@ tomcruise81 يمكنك محاولة استخدام البرنامج المساعد helm 2to3 والترحيل من helm2 إلى إصدار helm3 وحذف --force إذا كنت تستخدمه مسبقًا.
إنه عمل لنا.
بالنسبة لي ويبدو وكأنه لشخص آخر --force لديه سلوك خاطئ ويجب أن يتعامل مع هذه الحالة بحقل ثابت بالنسبة لي

alexandrsemak - شكرا على التوصية. في المثال الخاص بي ، أرى هذا على مخطط تم تثبيته أو ترقيته فقط باستخدام helm 3.

نفس المشكلة بالنسبة لي! استخدام

$ helm install my-release xxxxx
$ helm upgrade --install --force my-release xxxxx

في حالتي ، لا أقوم بتعريف ClusterIP على أي من الخدمات المستخدمة في الرسم البياني الخاص بي ، لكنني أواجه نفس المشكلة (انظر المواصفات أدناه):

spec:
  type: {{ .Values.service.type }}
  {{- if and (eq .Values.service.type "LoadBalancer") (not (empty .Values.service.loadBalancerIP)) }}
  loadBalancerIP: {{ .Values.service.loadBalancerIP }}
  {{- end }}
  ports:
    - name: htttp-XXX
      port: {{ .Values.service.port }}
      targetPort: XXX
      {{- if and (or (eq .Values.service.type "NodePort") (eq .Values.service.type "LoadBalancer")) (not (empty .Values.service.nodePort)) }}
      nodePort: {{ .Values.service.nodePort }}
      {{- else if eq .Values.service.type "ClusterIP" }}
      nodePort: null
      {{- end }}
  selector:
    app.kubernetes.io/name: XXX
    app.kubernetes.io/instance: {{ .Release.Name }}

كما قال المستخدمون الآخرون من قبل ، السبب هو أن Kubernetes يعين تلقائيًا للخدمة مجموعة IP في المرة الأولى (على سبيل المثال ، clusterIP: 10.96.26.65 ) ويتعارض مع clusterIP: "" عند محاولة الترقية. يرجى ملاحظة أنني لا أقوم بإنشاء هذا في القوالب الخاصة بي: clusterIP: ""

يرجى إعادة فتح هذا @ bacongobbler

لدي نفس المشكلة.

@ juan131Ronsevet: إزالة --force معنى تغييرها.

تواجه نفس المشكلة ، على الرسوم البيانية المخصصة.
نحن لا نحدد العنقودية في أي مكان.
هيلم v3.0.2
kubectl 1.14.8

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

نفس الشيء بالنسبة لي - لقد أضفت تسمية إضافية للخدمة وواجهت هذا الخطأ. كما أنني لا أحدد ClusterIP في أي مكان - يرجى إعادة فتح المشكلة

bacongobbler نحن ننشر StorageClass كجزء من مخططنا ومعلمات StorageClass غير قابلة للتغيير. لذلك في الإصدار التالي ، عندما نقوم بتحديث قيمة بعض معلمات StorageClass ، يفشل أيضًا helm upgrade --force .
لست متأكدًا من كيفية التعامل مع هذه الحالة لتحديث StorageClasses. أي اقتراحات؟

Error: UPGRADE FAILED: failed to replace object: StorageClass.storage.k8s.io "ibmc-s3fs-standard-cross-region" is invalid: parameters: Forbidden: updates to parameters are forbidden.

كانت تعمل بشكل جيد في helm v2 حيث تم استخدام helm upgrade --force لفرض الحذف وإعادة إنشاء StorageClass .

إذا كان أي شخص يعاني من أعراض ليست نتيجة الشرح المقدم في https://github.com/helm/helm/issues/6378#issuecomment -557746499 ، يرجى فتح مشكلة جديدة بالنتائج التي توصلت إليها وكيف يمكننا إعادة إنتاج من نهايتنا؟

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

شكرا لك!

mssachan انظر # 7082 ومسودة الاقتراح في # 7431 لحالة الاستخدام الخاصة بك. يهدف هذا الاقتراح إلى تنفيذ kubectl replace —force ، والذي سيكون مشابهًا لسلوك Helm 2 helm install —force .

mssachan انظر # 7082 ومسودة الاقتراح في # 7431 لحالة الاستخدام الخاصة بك. يهدف هذا الاقتراح إلى تنفيذ kubectl replace —force ، والذي سيكون مشابهًا لسلوك Helm 2 helm install —force .

من الجيد أن هذا ما يحدث. حتى مع حذف العلم --force ، ما زلت أحصل على الخطأ عند ترقية الرسوم البيانية. على سبيل المثال ، مع cert-manager :

2020-03-05 12:15:19 CRITICAL: Command returned [ 1 ] exit code and error message [ Error: UPGRADE FAILED: cannot patch "cert-manager-cainjector" with kind Deployment: Deployment.apps "cert-manager-cainjector" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"cainjector", "app.kubernetes.io/instance":"cert-manager", "app.kubernetes.io/managed-by":"Helm", "app.kubernetes.io/name":"cainjector"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "cert-manager" with kind Deployment: Deployment.apps "cert-manager" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"cert-manager", "app.kubernetes.io/instance":"cert-manager", "app.kubernetes.io/managed-by":"Helm", "app.kubernetes.io/name":"cert-manager"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "cert-manager-webhook" with kind Deployment: Deployment.apps "cert-manager-webhook" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"webhook", "app.kubernetes.io/instance":"cert-manager", "app.kubernetes.io/managed-by":"Helm", "app.kubernetes.io/name":"webhook"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

mssachan انظر # 7082 ومسودة الاقتراح في # 7431 لحالة الاستخدام الخاصة بك. يهدف هذا الاقتراح إلى تنفيذ kubectl replace —force ، والذي سيكون مشابهًا لسلوك Helm 2 helm install —force .

من الجيد أن هذا ما يحدث. حتى مع حذف العلم --force ، ما زلت أحصل على الخطأ عند ترقية الرسوم البيانية. على سبيل المثال ، مع cert-manager :

2020-03-05 12:15:19 CRITICAL: Command returned [ 1 ] exit code and error message [ Error: UPGRADE FAILED: cannot patch "cert-manager-cainjector" with kind Deployment: Deployment.apps "cert-manager-cainjector" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"cainjector", "app.kubernetes.io/instance":"cert-manager", "app.kubernetes.io/managed-by":"Helm", "app.kubernetes.io/name":"cainjector"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "cert-manager" with kind Deployment: Deployment.apps "cert-manager" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"cert-manager", "app.kubernetes.io/instance":"cert-manager", "app.kubernetes.io/managed-by":"Helm", "app.kubernetes.io/name":"cert-manager"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "cert-manager-webhook" with kind Deployment: Deployment.apps "cert-manager-webhook" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"webhook", "app.kubernetes.io/instance":"cert-manager", "app.kubernetes.io/managed-by":"Helm", "app.kubernetes.io/name":"webhook"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

@ sc250024 لدي نفس المشكلة بالضبط بعد أن قمت بترقية helm v2 إلى v3. كان تقدم الترقية سلسًا ولم يكن هناك خطأ ، ثم أحاول ترقية مدير الشهادات من الدفة ، وفشل مع نفس الإخراج.

# helm upgrade cert-manager jetstack/cert-manager --namespace cert-manager --atomic --cleanup-on-fail

# helm version
version.BuildInfo{Version:"v3.1.1", GitCommit:"afe70585407b420d0097d07b21c47dc511525ac8", GitTreeState:"clean", GoVersion:"go1.13.8"}

أي حلول بديلة عند عدم استخدام القوة ، أو عدم تعيين أي خيار على الإطلاق حول clusterIP . هذا بيان الخدمة الخاص بي:

apiVersion: v1
kind: Service
metadata:
  name: "{{ .Values.deploymentBaseName }}-{{ .Values.skaffoldUser }}"
  labels:
    name: "{{ .Values.deploymentBaseName }}-{{ .Values.skaffoldUser }}"
spec:
  ports:
    - port: {{ .Values.servicePort }}
      targetPort: {{ .Values.containerPort }}
      protocol: TCP
      name: http
    - name: debugger-http
      port: {{ .Values.debuggerPort }}
      targetPort: {{ .Values.debuggerPort }}
      protocol: TCP
  selector:
    app: "{{ .Values.deploymentBaseName }}-{{ .Values.skaffoldUser }}"
  type: ClusterIP

davidfernandezm هل وجدت حلاً لهذا من قبل؟ أرى نفس الشيء من طرفي ويتم تحديد خدماتي تمامًا كما هي خدماتك. لم يتم تعيين أي خيار لـ clusterIP ، ومع ذلك لا يزال Helm يفشل في الترقية.

كذلك هنا

الحصول على هذا أيضا ، إعادة: التعليقين أعلاه.

يرجى تقديم مزيد من المعلومات. لا يمكننا مساعدتك دون فهم السبب أو كيفية ظهور هذه المشكلة في حالتك. شكرا.

antonakv هذه 7956
bacongobbler مزيد من المعلومات

لدي نفس المشكلة ، حتى بدون تعيين نوع الخدمة أو عنوان IP للمجموعة باستخدام helm v3.0.0-rc.2 إذا استخدمت الخيار --force مع أمر helm update --install. بدون - القوة تعمل بشكل جيد

رائع! لقد استوحيت من إجابتك ، أنه لا بد لي من التعليق على سطر force: .. في helmfile yaml:

helmDefaults:
  tillerless: true
  verify: false
  wait: true
  timeout: 600
  # force: true <---- THI ONE IS COMMENTED

إنه يعمل 🎉

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

لدي نفس المشكلة ، حتى بدون تعيين نوع الخدمة أو عنوان IP للمجموعة باستخدام helm v3.0.0-rc.2 إذا استخدمت الخيار --force مع أمر helm update --install. بدون - القوة تعمل بشكل جيد

أفضل حل ، إنه يعمل معي ، شكرًا لك!

نواجه نفس المشكلة ولم نتمكن من العثور على أي حل لحلها.
من السهل التكاثر

helm install in stable/inbucket 
helm upgrade in stable/inbucket 
Error: UPGRADE FAILED: cannot patch "in-inbucket" with kind Service: Service "in-inbucket" is invalid: spec.clusterIP: Invalid value: "": field is immutable

كنت أتساءل لماذا لا يعمل --force هنا ، أليس من المفترض أن force resource updates through a replacement strategy إذا كانت هذه إستراتيجية بديلة ، فيجب إزالة الخدمة ثم استبدالها؟

bacongobbler لقد وصلت إلى هذا الموضوع بعد التحقق من https://github.com/helm/helm/issues/7956

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

إصدار خوذة: 3.4.1

"helm -n kube-system get manifest CHART_NAME | grep clusterIP" لا يظهر أي نتائج.

خطأ:
field is immutable && failed to replace object: Service "SERVICE_NAME" is invalid: spec.clusterIP: Invalid value: "": field is immutable

نفس الشرح المقدم في https://github.com/helm/helm/issues/6378#issuecomment -557746499 ينطبق أيضًا هنا في حالتك @ nick4fake. يتمثل الاختلاف في أنه مع --force ، فإنك تطلب من Kubernetes أخذ البيان الذي تم عرضه بالكامل والكتابة فوق الكائن الحي الحالي بقوة. نظرًا لأن البيان الخاص بك لا يحتوي على حقل clusterIP ، يأخذ Kubernetes ذلك ويفترض أنك تحاول إزالة الحقل clusterIP من الكائن الحي ، ومن هنا الخطأ Invalid value: "": field is immutable .

bacongobbler أنا آسف حقًا إذا الأجزاء الداخلية لشركة Helm.

"توصيتي هي تغيير إخراج القالب. إذا لم يتم توفير عنصر blockIP كقيمة ، فلا تقم بتعيين القيمة على سلسلة فارغة ... احذف الحقل بالكامل."

فما هو الحل؟ هل يعني ذلك أنه لا يمكن استخدام علامة "--force" على الإطلاق إذا لم يتم تعيين حقل الكتلة IP على قيمة ثابتة؟

بقدر ما يتعلق الأمر Kubernetes: نعم.

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

من ناحية أخرى ، يعد Helm مضللًا أيضًا ، لأن --force يوصف بأنه "فرض تحديثات الموارد من خلال إستراتيجية الاستبدال". بينما في الواقع لا يقوم بأي بديل ، فإنه يحاول فقط استبدال الموارد بقوة (سيكون من الأفضل تسمية العلامة --force-overwrite ). يبدو الاستبدال القوي وكأنه حذف وإعادة إنشاء مرة أخرى (قد يكون هناك علامة --force-recreate ). بالطبع ، قد يكون استخدام --force-recreate خطيرًا بعض الشيء لبعض الموارد ، لكنه سينجح دائمًا.

على أي حال ، يمكن أن يقوم Helm بتنفيذ حل بديل لمثل هذا النوع من المشكلات. إذا فشل السلوك الحالي (الموصوف كـ --force-overwrite ) واكتشف خطأ حقل غير قابل للتغيير ، يجب حذف المورد وإعادة إنشائه (مثل --force-recreate ).