Helm: हेल्म 3 - nginx को अपग्रेड करें - spec.clusterIP: अमान्य मान: "": फ़ील्ड अपरिवर्तनीय है

यह संभवत: हेल्म 3 में हाल ही में हुए बदलाव से संबंधित है जहां अब यह कुबेक्टल के समान तीन-तरफ़ा मर्ज पैच रणनीति का उपयोग करता है। देखें #6124

यदि आप इसे पुन: पेश करने के तरीके पर कदम प्रदान कर सकते हैं, तो यह अद्भुत होगा। धन्यवाद!

ज़रूर!

मैं एक अक्स क्लस्टर बनाया।

मैं MC_* संसाधन समूह में एक सार्वजनिक IP बनाता हूं।

मैंने उस सार्वजनिक आईपी के आईपी पते को $ip में संग्रहीत किया है।

फिर मूल रूप से उस आदेश को दो बार चलाया:

./हेल्म अपग्रेड --इंस्टॉल
--सेट rbac.create=false
--सेट नियंत्रक.प्रतिकृतिगणना=2
--सेट कंट्रोलर.service.loadBalancerIP=$ip
--प्रतीक्षा मुख्य-प्रवेश स्थिर/nginx-प्रवेश

यह वैसा ही है जैसा https://docs.microsoft.com/en-us/azure/aks/ingress-static-ip में किया जाता है

अंतर यह है कि मैं दो बार हेलम अपग्रेड --इंस्टॉल करता हूं। इसका उद्देश्य मेरे सीआई/सीडी में सिंगल कमांड लाइन (बिना शर्त) रखना है।

अगर आपको पुन: पेश करने के लिए और विवरण चाहिए तो मुझे बताएं।

क्या यह पुनरुत्पादन के लिए पर्याप्त था? अगर यह मदद करता है तो मैं एक बैश स्क्रिप्ट प्रदान कर सकता हूं।

क्षमा करें, सप्ताह के लिए हेल्म समिट ईयू में बंद हूं इसलिए मेरे पास अभी तक प्रतिक्रिया देने का समय नहीं है।

आह ... कोई चिंता नहीं। शिखर का आनंद लें!

मैं भी इस समस्या का सामना कर रहा हूँ

$ 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 चार्ट के साथ एक मुद्दा है, हेल्म 3 नहीं। डिफ़ॉल्ट रूप से, चार्ट हमेशा 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-values.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

जैसा कि आप नीचे देख सकते हैं, टेम्पलेट में क्लस्टरआईपी नहीं है

पतवार टेम्पलेट INGx स्थिर/nginx-प्रवेश -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 पैरामीटर के बिना तैनात किया था, और हेलम v3 मूल मैनिफेस्ट के साथ 3-तरफा विलय करने का प्रयास कर रहा है, जिसमें इसमें 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 में मौजूदा मैनिफेस्ट के साथ विलय को छोड़ने का कोई तरीका था

क्षमा करें, मुझे यह निर्दिष्ट करना चाहिए था कि जब रिलीज़ प्रारंभ में स्थापित हो तो इन मानों को सेट करने की आवश्यकता होती है। किसी मौजूदा रिलीज़ को अपडेट करना मुश्किल साबित हो सकता है...

मैं मेट्रिक-सर्वर-2.8.8 के साथ इस समस्या में भाग रहा हूं, जिसके मूल्यों में कोई क्लस्टरआईपी नहीं है, और कुछ अन्य चार्ट, हेलम v3.0.0-rc.2 के साथ। कोई सलाह? मुझे यकीन नहीं है कि कैसे आगे बढ़ना है।

मेरी समस्या हेलमफाइल v0.95.0 के साथ प्रतीत होती है। मैं वहां इसका पीछा करूंगा :)

मेरे पास एक ही समस्या है, यहां तक ​​​​कि हेल्म v3.0.0-rc.2 के साथ सेवा प्रकार या क्लस्टरआईपी सेट किए बिना भी अगर मैं --force विकल्प का उपयोग हेल्म अपडेट --इंस्टॉल कमांड के साथ करता हूं। --force के बिना यह ठीक काम करता है

@johannges , मैं बस वही पोस्ट करने वाला था। :+1:

omitClusterIP: true सेटिंग डिफ़ॉल्ट बैकएंड और नियंत्रक सेवाओं के लिए काम करती प्रतीत होती है लेकिन मीट्रिक एक के लिए नहीं।

मुझे लगता है कि यह उन्नयन के दौरान --force विकल्प के साथ पतवार के साथ समस्या है।
हेल्म सेवा को फिर से बनाने की कोशिश कर रहा है लेकिन यह spec.clusterIP को भी प्रतिस्थापित करता है इसलिए यह त्रुटि फेंक देता है।
मैं अपने स्वयं के कस्टम चार्ट का उपयोग करके इसकी पुष्टि कर सकता हूं।
Error: UPGRADE FAILED: failed to replace object: Service "litespeed" is invalid: spec.clusterIP: Invalid value: "": field is immutable

वास्तव में यह मेरी ओर से एक गलती थी, सेवा (या चार्ट) के आरंभीकरण पर क्लस्टरआईपी परिभाषा को छोड़ना ठीक काम करता है

मैं मौजूदा परिनियोजित _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 से सहमत हैं कि यह हेल्म v3 थ्री-वे मर्ज पैच रणनीति से संबंधित दिखता है, जिसके परिणामस्वरूप कुबेरनेट्स पहली रचना के बाद अपरिवर्तनीय/अपरिवर्तनीय मानता है कि अद्यतन/पैच के लिए फ़ील्ड (यहां तक ​​​​कि पहले के समान मानों के साथ) में गुजरने की संभावना है।

यदि कोई व्यक्ति टेराफॉर्म के माध्यम से हेल्म v3 का उपयोग करके यहां समाप्त होता है, क्योंकि आप इसे सीधे --force का उपयोग नहीं करने के लिए नहीं कह सकते हैं, तो मुझे helm delete का उपयोग करके चार्ट को मैन्युअल रूप से हटाने में सफलता मिली और फिर टेराफॉर्म को फिर से चलाना। यह बेकार है लेकिन यह काम करता है।

संपादित करें: पूरी त्रुटि: ("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 में इस मुद्दे को उठाया। मैं इसे और अधिक विस्तार से समझाने की कोशिश करूंगा ....

जैसा कि अन्य ने बताया है, समस्या तब उत्पन्न होती है जब एक चार्ट एक खाली स्ट्रिंग के साथ क्लस्टरआईपी को परिभाषित करता है। जब सेवा स्थापित हो जाती है, तो कुबेरनेट्स इस क्षेत्र को उस क्लस्टरआईपी के साथ भर देता है जिसे उसने सेवा को सौंपा था।

जब 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" , और प्रस्तावित स्थिति "" । हेल्म ने पाया कि उपयोगकर्ता ने clusterIP को "172.17.0.1" से "" में बदलने का अनुरोध किया, इसलिए इसने एक पैच की आपूर्ति की।

हेल्म 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: ""

अन्यथा, हेल्म सेवा के क्लस्टरआईपी को ऑटो-जेनरेट किए गए आईपी पते से खाली स्ट्रिंग में बदलने की कोशिश करेगा, इसलिए त्रुटि संदेश।

उम्मीद है की यह मदद करेगा!

एक अस्थायी समाधान के रूप में यदि आप इसे अभी के लिए काम करने की कोशिश कर रहे हैं, जबकि यह समस्या हल हो जाती है, तो मैंने पाया कि अगर मैंने निम्नलिखित किया तो मैं एक अद्यतन करने में सक्षम था:

1. नियंत्रक और डिफ़ॉल्ट-बैकएंड के लिए क्लस्टरआईपी मान प्राप्त करें:
   kubectl get svc | grep ingress
2. अपनी मौजूदा हेलम मान फ़ाइल में निम्नलिखित ओवरराइट जोड़ें:
   controller: service: clusterIP: <cluster-ip-address-for-controller> defaultBackend: service: clusterIP: <cluster-ip-address-for-default-backend>
3. अद्यतन निष्पादित करें।

मैंने अपने द्वारा चलाए जा रहे क्लस्टर के लिए इसका परीक्षण किया है और इसके लिए किसी मनोरंजन की आवश्यकता नहीं है।

वह भी काम करता है। गुड कॉल @ट्रेचर। --set माध्यम से समान मान सेट करना या आपकी मान फ़ाइल में कोई पैच उत्पन्न नहीं होता है, क्योंकि अपग्रेड clusterIP के मान को बदलना नहीं चाहता है।

ऊपर वर्णित तीन-तरफा मर्ज पैच व्यवहार के अनुसार जानबूझकर काम करने के रूप में बंद करना। इन चार्टों के लिए https://github.com/helm/helm/issues/6378#issuecomment-557746499 में ऊपर दी गई अनुशंसा का पालन करने के लिए कार्रवाई आइटम है। हेल्म की ओर से यहाँ कुछ नहीं करना है। :)

https://github.com/helm/charts/pull/19146/files बनाई गई! धन्यवाद @bacongobbler

@ zen4ever ने #6378 (टिप्पणी) में इस मुद्दे को उठाया। मैं इसे और अधिक विस्तार से समझाने की कोशिश करूंगा ....

जैसा कि अन्य ने बताया है, समस्या तब उत्पन्न होती है जब एक चार्ट एक खाली स्ट्रिंग के साथ क्लस्टरआईपी को परिभाषित करता है। जब सेवा स्थापित हो जाती है, तो कुबेरनेट्स इस क्षेत्र को उस क्लस्टरआईपी के साथ भर देता है जिसे उसने सेवा को सौंपा था।

जब 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" , और प्रस्तावित स्थिति "" । हेल्म ने पाया कि उपयोगकर्ता ने clusterIP को "172.17.0.1" से "" में बदलने का अनुरोध किया, इसलिए इसने एक पैच की आपूर्ति की।

हेल्म 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: "" पूरी तरह से मान फ़ाइल में टिप्पणी की गई हो। यह सेट होने पर रेंडर किए गए मैनिफ़ेस्ट से इसे छोड़ देता है और भविष्य में होने वाले सिरदर्द से बचना चाहिए। हालांकि यदि हेलम3 और वर्तमान हेलम स्थिति का उपयोग clusterIP: "" सेट है, तो किसी को मान फ़ाइलों में क्लस्टरआईपी पते को हार्डकोड करने की आवश्यकता होती है।

यही कारण है कि इस मामले में --set controller.service.omitClusterIP=true काम करता है।

TL; DR अपने सेवा टेम्प्लेट में ऐसा न करें:

clusterIP: ""

अन्यथा, हेल्म सेवा के क्लस्टरआईपी को ऑटो-जेनरेट किए गए आईपी पते से खाली स्ट्रिंग में बदलने की कोशिश करेगा, इसलिए त्रुटि संदेश।

उम्मीद है की यह मदद करेगा!

अरे @bacongobbler , हमने हेलम v3 में माइग्रेट करने के दौरान एक ही समस्या का सामना किया। हम सेवा में type: ClusterIP का उपयोग करते हैं लेकिन ClusterIP को बिल्कुल छोड़ देते हैं और हमें मिलता है:

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

हमारे हेलम टेम्पलेट में हमारे पास spec.clusterIP: है लेकिन हेल्म 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 }}

यहां भी यही समस्या। बात यह है कि हमने सेवा को छुआ नहीं है। यह इनग्रेड है जिसे अपग्रेड से पहले बदल दिया गया था।

यह अपरिवर्तनीय फ़ील्ड वाले संसाधनों पर प्रभाव डालता है यदि --force ध्वज को helm upgrade --install से हटा दें और अपरिवर्तनीय फ़ील्ड को स्पर्श न करें तो सब कुछ ठीक काम करता है। लेकिन अगर आप संसाधनों का ह्रास करना चाहते हैं ??? आपको संसाधनों को फिर से बनाने की आवश्यकता है लेकिन हेलम 3 संसाधनों को अपग्रेड नहीं करेगा ....
@बेकोंगोब्लर ^^^

हेलम 3 द्वारा नए apiVersion के साथ अद्यतन एचपीए की कोशिश की:
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 साल शुरू करने का तरीका क्या है :)
मुझे लगता है कि सामान्य तौर पर हम चार्ट में एक विन्यास योग्य मूल्य के रूप में क्लस्टरआईपी प्रदान करते समय आग से खेल रहे हैं, और विशेष रूप से एक उपकरण/व्यक्ति/पीआर को पूरी तरह से दोष नहीं दे सकते।
यदि क्लस्टरआईपी को कॉन्फ़िगर करने योग्य मान होना चाहिए, तो डिफ़ॉल्ट रूप से यह रेंडर किए गए टेम्पलेट में नहीं होना चाहिए, यह https://github.com/helm/charts/blob/270172836fd8cf56d787cf7d04d938856de0c794/stable के अनुसार मान फ़ाइलों में मेरी टिप्पणी का विचार है।

यह, अगर मैं गलत नहीं हूं, तो उन लोगों के लिए भविष्य के सिरदर्द को रोकना चाहिए जो चार्ट को उस परिवर्तन के रूप में स्थापित करते हैं। लेकिन हममें से (स्वयं शामिल) जिन्होंने इसे पहले स्थापित किया था, और फिर हेल्म 3 में माइग्रेट किया था, मुझे डर है कि हमारे मूल्यों की फाइलों में मौजूदा क्लस्टरआईपी मूल्यों को हार्डकॉर्डिंग करना या चार्ट को अनइंस्टॉल करना और पुनर्स्थापित करना (डाउनटाइम का कारण बनता है!) एकमात्र विकल्प हैं I देखो।

राय मेरे अपने हैं, मुझे शीर्ष पर काम करने के लिए भुगतान नहीं किया जाता है, बस आप जैसे अंतिम उपयोगकर्ता हैं। जिन लोगों को इस पूरे समय पर काम करने के लिए भुगतान किया जाता है वे अधिक अंतर्दृष्टि प्रदान करने में सक्षम हो सकते हैं।

नया साल मुबारक हो और शुभकामनाएँ! हिम्मत मत हारो, हम सब मिलकर इसे बेहतर बना सकते हैं।

अरे @bacongobbler , हमने हेलम v3 में माइग्रेट करने के दौरान एक ही समस्या का सामना किया। हम सेवा में type: ClusterIP का उपयोग करते हैं लेकिन ClusterIP को बिल्कुल छोड़ देते हैं और हमें मिलता है:

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

हमारे हेलम टेम्पलेट में हमारे पास spec.clusterIP: है लेकिन हेल्म 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 सेवा टेम्पलेट का हिस्सा नहीं है, फिर भी हेल्म 3.0.2 और helm upgrade ... --force --install कॉल के साथ, हम यह भी देख रहे हैं:

त्रुटि: अपग्रेड विफल: वस्तु को बदलने में विफल: सेवा "डमी" अमान्य है: spec.clusterIP: अमान्य मान: "": फ़ील्ड अपरिवर्तनीय है

कृपया फिर से खोलें।

@tomcruise81 कृपया --force पर थ्रेड के लिए https://github.com/helm/helm/issues/7350 देखें। इसके परिणामस्वरूप वही त्रुटि होती है, लेकिन यह kubectl replace के काम करने के तरीके के कारण होता है। यह यहाँ क्या वर्णित स्थिति से एक अलग मुद्दा है, जो सेवा clusterIPs से संबंधित है और तीन तरह से मर्ज पैच रणनीति ( 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 , हमने हेलम v3 में माइग्रेट करने के दौरान एक ही समस्या का सामना किया। हम सेवा में type: ClusterIP का उपयोग करते हैं लेकिन ClusterIP को बिल्कुल छोड़ देते हैं और हमें मिलता है:
Error: UPGRADE FAILED: failed to replace object: Service "dummy" is invalid: spec.clusterIP: Invalid value: "": field is immutable
हमारे हेलम टेम्पलेट में हमारे पास spec.clusterIP: है लेकिन हेल्म 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 - _सेवा "डमी" में परिणाम है_
• helm template ... | kubectl apply -f - - काम करता है
• helm template ... | kubectl replace -f - - _सेवा "डमी" में परिणाम है_
• helm template ... | kubectl replace --force -f - - काम करता है

कुबेक्टल संस्करण - 1.14.6
पतवार संस्करण - 3.0.2

@ tomcruise81 आप हेल्म प्लगइन 2to3 का उपयोग करने का प्रयास कर सकते हैं और हेल्म 2 से हेल्म 3 रिलीज में माइग्रेट कर सकते हैं और यदि आप पहले इसका इस्तेमाल करते हैं तो --force हटा दें।
यह हमारे लिए काम है।
मेरे लिए और दूसरे लोगों की तरह दिखता है --force में गलत व्यवहार है और इस मामले को मेरे लिए अपरिवर्तनीय क्षेत्र के साथ संभालना चाहिए

@alexandrsemak - सिफारिश के लिए धन्यवाद। मेरे उदाहरण में, मैं इसे एक चार्ट पर देख रहा हूं जिसे केवल हेल्म 3 का उपयोग करके स्थापित या अपग्रेड किया गया है।

मेरे लिए वही मुद्दा! का उपयोग करते हुए

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

मेरे मामले में, मैं अपने चार्ट पर उपयोग की जाने वाली किसी भी सेवा पर क्लस्टरआईपी को परिभाषित नहीं कर रहा हूं, लेकिन मुझे एक ही समस्या का सामना करना पड़ रहा है (नीचे चश्मा देखें):

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 }}

जैसा कि अन्य उपयोगकर्ताओं ने पहले कहा था, इसका कारण यह है कि कुबेरनेट्स पहली बार सेवा को एक क्लस्टरआईपी (जैसे . clusterIP: 10.96.26.65 ) ऑटो-असाइन करता है और जब आप अपग्रेड करने का प्रयास करते हैं तो यह clusterIP: "" साथ विरोध करता है। कृपया ध्यान दें कि मैं इसे अपने टेम्प्लेट पर नहीं बना रहा हूं: clusterIP: ""

कृपया इसे फिर से खोलें @bacongobbler

मेरे साथ भी वही दिक्कत है।

@ जुआन 131 @ रोनसेवेट : हटाएं --force अर्थ बदल गया।

कस्टम चार्ट पर एक ही समस्या का सामना करना पड़ रहा है।
हम क्लस्टरिप को कहीं भी परिभाषित नहीं करते हैं।
पतवार v3.0.2
कुबेक्ट्ल 1.14.8

मुद्दा यह है कि कभी-कभी एक चार्ट विफल स्थिति में रहता है, भले ही पॉड्स बनाए और चल रहे हों। अगर हम उसी रिलीज को अपग्रेड करने का प्रयास करते हैं तो यह बिना बल के काम नहीं करता है।
चूंकि पॉड चल रहे हैं, इसलिए रिलीज को हटाया और फिर से नहीं बनाया जा सकता है।
"बल" का उपयोग करने का कोई तरीका है

मेरे लिए भी - मैंने अभी सेवा में अतिरिक्त लेबल जोड़ा है और इस त्रुटि का सामना करना पड़ा है। इसके अलावा मैं क्लस्टरआईपी को कहीं भी परिभाषित नहीं करता - कृपया इस मुद्दे को फिर से खोलें

@bacongobbler हम अपने चार्ट के हिस्से के रूप में StorageClasses को तैनात कर रहे हैं और 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.

यह हेल्म v2 में ठीक काम कर रहा था क्योंकि helm upgrade --force को हटाने और StorageClass को फिर से बनाने के लिए उपयोग किया जाता था ।

यदि कोई ऐसे लक्षणों का अनुभव कर रहा है जो https://github.com/helm/helm/issues/6378#issuecomment -557746499 में दिए गए स्पष्टीकरण का परिणाम नहीं हैं, तो क्या आप कृपया अपने निष्कर्षों के साथ एक नया मुद्दा खोल सकते हैं और हम कैसे पुन: पेश कर सकते हैं यह हमारे अंत में?

ओपी द्वारा उठाया गया मुद्दा ऊपर दिए गए परिदृश्य के कारण था, जहां एक चार्ट क्लस्टरआईपी को स्थापित करने पर एक खाली स्ट्रिंग पर सेट करता है। यह पूरी तरह से संभव है कि ऐसे अन्य परिदृश्य हैं जहां यह विशेष मामला सामने आ सकता है, जैसे कि अन्य ने --force ध्वज के उपयोग के साथ उल्लेख किया है। उन मामलों पर अलग से चर्चा की जानी चाहिए, क्योंकि निदान और समाधान पहले दी गई सलाह से भिन्न हो सकते हैं।

आपको धन्यवाद!

@mssachan अपने उपयोग के मामले में # 7082 और # 7431 में मसौदा प्रस्ताव देखें। उस प्रस्ताव का उद्देश्य kubectl replace —force को लागू करना है, जो हेल्म 2 के helm install —force के व्यवहार के समान होगा।

@mssachan अपने उपयोग के मामले में # 7082 और # 7431 में मसौदा प्रस्ताव देखें। उस प्रस्ताव का उद्देश्य kubectl replace —force को लागू करना है, जो हेल्म 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 को लागू करना है, जो हेल्म 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 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"}

जब --force का उपयोग नहीं किया जाता है, या 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 लिए कोई विकल्प सेट नहीं किया जा रहा है, और फिर भी हेलम अभी भी अपग्रेड पर विफल रहता है।

मेरा भी यही विचार है

इसे भी प्राप्त करना, पुन: उपरोक्त दो टिप्पणियां।

कृपया अधिक जानकारी प्रदान करें। कारण को समझे बिना या आपके मामले में यह समस्या कैसे सामने आती है, हम आपकी मदद नहीं कर सकते। धन्यवाद।

@antonakv यह अंक 7956 का डुप्लिकेट है
@bacongobbler अधिक जानकारी

मेरे पास एक ही समस्या है, यहां तक ​​​​कि हेल्म v3.0.0-rc.2 के साथ सेवा प्रकार या क्लस्टरआईपी सेट किए बिना भी अगर मैं --force विकल्प का उपयोग हेल्म अपडेट --इंस्टॉल कमांड के साथ करता हूं। --force के बिना यह ठीक काम करता है

ठंडा! मैंने आपके उत्तर से प्रेरित किया, कि मुझे force: .. लाइन पर हेल्मफाइल yaml में टिप्पणी करनी है:

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

यह काम करता है

मैंने उपरोक्त सभी की कोशिश की, किसी ने भी मेरे लिए काम नहीं किया। मुझे अपने चार्ट से nginx-ingress को अक्षम करना था, एक अपग्रेड करना था, इसे फिर से सक्षम करना था, और फिर से अपग्रेड करना था। इससे क्लाउड प्रदाता द्वारा निर्दिष्ट आईपी पते में परिवर्तन हुआ, लेकिन कोई नुकसान नहीं हुआ।

मेरे पास एक ही समस्या है, यहां तक ​​​​कि हेल्म v3.0.0-rc.2 के साथ सेवा प्रकार या क्लस्टरआईपी सेट किए बिना भी अगर मैं --force विकल्प का उपयोग हेल्म अपडेट --इंस्टॉल कमांड के साथ करता हूं। --force के बिना यह ठीक काम करता है

सबसे अच्छा समाधान, यह मेरे लिए काम करता है, धन्यवाद!

हमें एक ही समस्या हो रही है और इसके आसपास कोई काम नहीं मिल रहा है।
इसे पुन: पेश करना बहुत आसान है

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 की जाँच के बाद इस सूत्र पर पहुँच गया हूँ

पिछले सभी टिप्पणीकारों की तरह: हमारे पास टेम्प्लेट में "क्लस्टरआईपी" बिल्कुल नहीं है, लेकिन नवीनतम हेल्म के साथ त्रुटि अभी भी मौजूद है यदि --force ध्वज का उपयोग किया जाता है।

पतवार संस्करण: 3.4.1

"हेल्म-एन क्यूब-सिस्टम मेनिफेस्ट CHART_NAME | grep क्लस्टरआईपी" कोई परिणाम नहीं दिखाता है।

त्रुटि:
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 , आप कुबेरनेट्स को अपना पूरी तरह से प्रस्तुत मैनिफेस्ट लेने और वर्तमान लाइव ऑब्जेक्ट को जबरदस्ती ओवरराइट करने के लिए कह रहे हैं। चूंकि आपके मेनिफेस्ट में clusterIP फ़ील्ड नहीं है, कुबेरनेट्स इसे लेता है और मानता है कि आप clusterIP फ़ील्ड को लाइव ऑब्जेक्ट से निकालने का प्रयास कर रहे हैं, इसलिए त्रुटि Invalid value: "": field is immutable ।

@bacongobbler मुझे वास्तव में खेद है अगर मुझे यहां कुछ याद आती है, तो शायद मुझे

"मेरी सिफारिश टेम्पलेट आउटपुट को बदलने की होगी। यदि कोई क्लस्टरआईपी मान के रूप में प्रदान नहीं किया जा रहा है, तो मान को रिक्त स्ट्रिंग पर सेट न करें ... फ़ील्ड को पूरी तरह से छोड़ दें।"

तो समाधान क्या है? क्या इसका मतलब यह है कि "--force" ध्वज का उपयोग बिल्कुल नहीं किया जा सकता है यदि क्लस्टरआईपी फ़ील्ड कुछ स्थिर मान पर सेट नहीं है?

जहाँ तक कुबेरनेट्स का संबंध है: हाँ।

मेरी समझ के अनुसार यह कुबेरनेट्स के साथ एक समस्या है, क्योंकि "बलपूर्वक ओवरराइटिंग" उसी तरह से व्यवहार नहीं करता है जैसे "हटाना और फिर से बनाना"। क्या कोई अपस्ट्रीम बग है?

दूसरी ओर, हेल्म भी भ्रामक है, क्योंकि --force को "प्रतिस्थापन रणनीति के माध्यम से बल संसाधन अद्यतन" के रूप में वर्णित किया गया है। जबकि वास्तव में यह कोई प्रतिस्थापन नहीं करता है, यह केवल संसाधनों को जबरदस्ती अधिलेखित करने का प्रयास करता है (ध्वज को नाम देना बेहतर होगा --force-overwrite )। ज़बरदस्ती प्रतिस्थापन फिर से हटाने और फिर से बनाने जैसा लगेगा (एक ध्वज हो सकता है --force-recreate )। बेशक, --force-recreate कुछ संसाधनों के लिए उपयोग करने के लिए थोड़ा खतरनाक हो सकता है, लेकिन यह हमेशा सफल होगा।

वैसे भी, हेल्म इस तरह के मुद्दों के लिए फ़ॉलबैक वर्कअराउंड लागू कर सकता है। यदि वर्तमान व्यवहार (जिसे --force-overwrite रूप में वर्णित किया गया है) विफल हो जाता है और एक अपरिवर्तनीय फ़ील्ड त्रुटि का पता लगाता है, तो उसे संसाधन को हटाना और फिर से बनाना चाहिए (जैसा कि --force-recreate )।