Helm: توجد ملفات Helm init في Kubernetes 1.16.0

تم إنشاؤها على ٦ سبتمبر ٢٠١٩  ·  83تعليقات  ·  مصدر: helm/helm

إخراج helm version : v2.14.3
إخراج kubectl version : العميل: v1.15.3 ، الخادم: v1.16.0-rc.1
موفر / النظام الأساسي للسحابة (AKS ، GKE ، Minikube وما إلى ذلك): خدمة IBM Cloud Kubernetes

$ helm init --service-account tiller
$HELM_HOME has been configured at /Users/xxxx/.helm.
Error: error installing: the server could not find the requested resource

$ helm init --debug --service-account tiller
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
. 
.
.

يبدو أن helm تحاول إنشاء نشر tiller باستخدام: apiVersion: extensions/v1beta1
وفقًا لـ: https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16
لم يعد مدعومًا.

bug

التعليق الأكثر فائدة

يعمل Sed التالي من أجلي:

helm init --service-account tiller --output yaml | sed 's<strong i="6">@apiVersion</strong>: extensions/v1beta1<strong i="7">@apiVersion</strong>: apps/v1@' | sed 's@  replicas: 1@  replicas: 1\n  selector: {"matchLabels": {"app": "helm", "name": "tiller"}}@' | kubectl apply -f -

المشكلة في حل mattymo (باستخدام kubectl patch --local) هي أنه يبدو أنه لا يعمل عندما تحتوي مدخلاته على موارد متعددة (هنا النشر والخدمة).

ال 83 كومينتر

لقد تجنبنا تحديث أداة الحراثة للتطبيقات / v1 في الماضي بسبب التعقيد مع وجود helm init --upgrade للتوفيق بين عمليات النشر على الحراثة extensions/v1beta1 و apps/v1 . يبدو أنه بمجرد أن نبدأ في دعم Kubernetes 1.16.0 ، سيتعين علينا التعامل مع هذه الحالة من الآن فصاعدًا والانتقال إلى الإصدار الأحدث.

إليك حل قصير المدى:

helm init --output yaml | sed 's<strong i="6">@apiVersion</strong>: extensions/v1beta1<strong i="7">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

في الواقع ، هذا ليس جيدًا بما يكفي. ما زلت أتلقى خطأ:

error validating data: ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec

يمكن تصحيح ذلك باستخدام:

/usr/local/bin/kubectl patch --local -oyaml -f - -p '{"spec":{"selector": {"app":"helm","name":"tiller"}}}'

لطيف! قد تكون قادرًا على تحقيق نفس التأثير باستخدام علامة --override من عمليات الاختراق المجنونة :)

لطيف! قد تكون قادرًا على تحقيق نفس التأثير باستخدام علامة --override من عمليات الاختراق المجنونة :)

نعم ، لكن يمكنني نسخه ولصقه من حيله الإلكتروني المجنونة ، في حين أن هذا helm init --override "apiVersion"="apps/v1" لا يعمل. حسنًا ، لا يعمل اختراق sed أيضًا.

الحل البديل الحالي يبدو كالتالي:

helm init --output yaml> حراثة. yaml
وتحديث الحارث.

  • التغيير إلى التطبيقات / v1
  • أضف حقل المحدد
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
....

يعمل Sed التالي من أجلي:

helm init --service-account tiller --output yaml | sed 's<strong i="6">@apiVersion</strong>: extensions/v1beta1<strong i="7">@apiVersion</strong>: apps/v1@' | sed 's@  replicas: 1@  replicas: 1\n  selector: {"matchLabels": {"app": "helm", "name": "tiller"}}@' | kubectl apply -f -

المشكلة في حل mattymo (باستخدام kubectl patch --local) هي أنه يبدو أنه لا يعمل عندما تحتوي مدخلاته على موارد متعددة (هنا النشر والخدمة).

تم إصدار Kubernetes 1.16.0 بالأمس: 18/9/2018.
تم كسر Helm في أحدث إصدار من Kubernetes ما لم يتم استخدام الحل أعلاه.

متى سيتم إصلاح هذه المشكلة ومتى سيتم تحرير Helm 2.15.0 ؟

إذا كنت ترغب في استخدام واحد أقل من ذلك :)
helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="6">@apiVersion</strong>: extensions/v1beta1<strong i="7">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

شكرا!

اليوم واجهت نفس المشكلة ، لقد غيرت التسمية بنفسي. قمت بتغيير التسمية إلى apps/v1 وأضفت الجزء selector ، اعتبارًا من الآن يعمل بشكل رائع ، فيما يلي ملف yaml الخاص بي:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
    spec:
      automountServiceAccountToken: true
      containers:
      - env:
        - name: TILLER_NAMESPACE
          value: kube-system
        - name: TILLER_HISTORY_MAX
          value: "0"
        image: gcr.io/kubernetes-helm/tiller:v2.14.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          httpGet:
            path: /liveness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        name: tiller
        ports:
        - containerPort: 44134
          name: tiller
        - containerPort: 44135
          name: http
        readinessProbe:
          httpGet:
            path: /readiness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        resources: {}
      serviceAccountName: tiller
status: {}

jbrette أنت بطلي! كنت أعاني مع مقطع selector .

اليوم واجهت نفس المشكلة ، لقد غيرت التسمية بنفسي. قمت بتغيير التسمية إلى apps/v1 وأضفت الجزء selector ، اعتبارًا من الآن يعمل بشكل رائع ، فيما يلي ملف yaml الخاص بي:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
    spec:
      automountServiceAccountToken: true
      containers:
      - env:
        - name: TILLER_NAMESPACE
          value: kube-system
        - name: TILLER_HISTORY_MAX
          value: "0"
        image: gcr.io/kubernetes-helm/tiller:v2.14.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          httpGet:
            path: /liveness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        name: tiller
        ports:
        - containerPort: 44134
          name: tiller
        - containerPort: 44135
          name: http
        readinessProbe:
          httpGet:
            path: /readiness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        resources: {}
      serviceAccountName: tiller
status: {}

كيف تتغير؟ هل يمكنك وصف المزيد من التفاصيل؟

اليوم واجهت نفس المشكلة ، لقد غيرت التسمية بنفسي. قمت بتغيير التسمية إلى apps/v1 وأضفت الجزء selector ، اعتبارًا من الآن يعمل بشكل رائع ، فيما يلي ملف yaml الخاص بي:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
    spec:
      automountServiceAccountToken: true
      containers:
      - env:
        - name: TILLER_NAMESPACE
          value: kube-system
        - name: TILLER_HISTORY_MAX
          value: "0"
        image: gcr.io/kubernetes-helm/tiller:v2.14.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          httpGet:
            path: /liveness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        name: tiller
        ports:
        - containerPort: 44134
          name: tiller
        - containerPort: 44135
          name: http
        readinessProbe:
          httpGet:
            path: /readiness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        resources: {}
      serviceAccountName: tiller
status: {}

@ gm12367 كيفية التغيير وهل يمكنك وصف المزيد من التفاصيل؟

اليوم واجهت نفس المشكلة ، لقد غيرت التسمية بنفسي. قمت بتغيير التسمية إلى apps/v1 وأضفت الجزء selector ، اعتبارًا من الآن يعمل بشكل رائع ، فيما يلي ملف yaml الخاص بي:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
    spec:
      automountServiceAccountToken: true
      containers:
      - env:
        - name: TILLER_NAMESPACE
          value: kube-system
        - name: TILLER_HISTORY_MAX
          value: "0"
        image: gcr.io/kubernetes-helm/tiller:v2.14.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          httpGet:
            path: /liveness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        name: tiller
        ports:
        - containerPort: 44134
          name: tiller
        - containerPort: 44135
          name: http
        readinessProbe:
          httpGet:
            path: /readiness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        resources: {}
      serviceAccountName: tiller
status: {}

@ gm12367 كيفية التغيير وهل يمكنك وصف المزيد من التفاصيل؟

على سبيل المثال ، يمكنك استخدام helm init --service-account tiller --tiller-namespace kube-system --debug لطباعة بيانات بتنسيق YAML ، وسيقوم الخيار --debug بهذا

@ gm12367 نعم ، يمكنني رؤية الطباعة ولكن فقط الإخراج. إذن ، ما هو الأمر الذي يمكنني تغيير الإخراج؟

@ gm12367 أريد تغيير التطبيقات / v1 وإضافة جزء محدد

@ puww1010 لقد قمت للتو بإعادة توجيه الإخراج في ملف ، ثم استخدمت VIM لتغييره. الأوامر أدناه كمرجع.

# helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml
# vim helm-init.yaml
# kubectl apply -f helm-init.yaml

إذا تم إعداد بيئة go الخاصة بك ولا يمكنك الانتظار حتى PR التالي الذي يعمل على إصلاح هذه المشكلة [Helm init متوافق مع Kubernetes 1.16] يتم دمج # 6462 ، يمكنك دائمًا القيام بما يلي:

يبني

mkdir p ${GOPATH}/src/k8s.io
cd ${GOPATH}/src/k8s.io 
git clone -b kube16 https://github.com/keleustes/helm.git
cd helm
make bootstrap build

اختبار:

kubectl version

Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:36:53Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:27:17Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
/bin/helm init --wait --tiller-image gcr.io/kubernetes-helm/tiller:v2.14.3
Creating /home/xxx/.helm
Creating /home/xxx/.helm/repository
Creating /home/xxx/.helm/repository/cache
Creating /home/xxx/.helm/repository/local
Creating /home/xxx/.helm/plugins
Creating /home/xxx/.helm/starters
Creating /home/xxx/.helm/cache/archive
Creating /home/xxx/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /home/xxx/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation

"" باش
kubectl get publish.apps / taler -loy -n kube-system -o yaml

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2019-09-22T01:01:11Z"
  generation: 1
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
  resourceVersion: "553"
  selfLink: /apis/apps/v1/namespaces/kube-system/deployments/tiller-deploy
  uid: 124001ca-6f31-417e-950b-2452ce70f522
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: helm
      name: tiller
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
    spec:
      automountServiceAccountToken: true
      containers:
      - env:
        - name: TILLER_NAMESPACE
          value: kube-system
        - name: TILLER_HISTORY_MAX
          value: "0"
        image: gcr.io/kubernetes-helm/tiller:v2.14.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /liveness
            port: 44135
            scheme: HTTP
          initialDelaySeconds: 1
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        name: tiller
        ports:
        - containerPort: 44134
          name: tiller
          protocol: TCP
        - containerPort: 44135
          name: http
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /readiness
            port: 44135
            scheme: HTTP
          initialDelaySeconds: 1
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 1
  conditions:
  - lastTransitionTime: "2019-09-22T01:01:23Z"
    lastUpdateTime: "2019-09-22T01:01:23Z"
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: "2019-09-22T01:01:11Z"
    lastUpdateTime: "2019-09-22T01:01:23Z"
    message: ReplicaSet "tiller-deploy-568db6b69f" has successfully progressed.
    reason: NewReplicaSetAvailable
    status: "True"
    type: Progressing
  observedGeneration: 1
  readyReplicas: 1
  replicas: 1
  updatedReplicas: 1

jbrette لا تزال تواجه نفس المشكلة بعد اتباع التعليمات الخاصة بك

jbrette لا تزال تواجه نفس المشكلة بعد اتباع التعليمات الخاصة بك

يبدو أنك كتبت "helm" بدلاً من "./bin/helm".... لذا فأنت تستخدم الإصدار القديم من الثنائي.

بعد التهيئة الناجحة ، لن تتمكن من تثبيت حزمة مخطط من المستودع حتى استبدال الامتدادات / v1beta1 فيه أيضًا.
فيما يلي كيفية تكييف أي مخطط من المستودع لـ k8s v1.16.0
المثال يعتمد على مخطط بروميثيوس.

git clone https://github.com/helm/charts
cd charts/stable

استبدل الامتدادات / v1beta1 بالسياسة / v1beta1 PodSecurityPolicy:

sed -i 's<strong i="11">@apiVersion</strong>: extensions/v1beta1<strong i="12">@apiVersion</strong>: policy/v1beta1@' `find . -iregex ".*yaml\|.*yml" -exec awk '/kind:\s+PodSecurityPolicy/ {print FILENAME}' {} +`

يتم التعامل مع إصدار apiVolicy الخاص بـ NetworkPolicy بشكل جيد بواسطة _helpers.tpl لتلك الرسوم البيانية حيث يتم استخدامه.

استبدل الامتدادات / v1beta1 بالتطبيقات / v1 في Deployment و StatefulSet و ReplicaSet و DaemonSet

sed -i 's<strong i="17">@apiVersion</strong>: extensions/v1beta1<strong i="18">@apiVersion</strong>: apps/v1@' `find . -iregex ".*yaml\|.*yml" -exec awk '/kind:\s+(Deployment|StatefulSet|ReplicaSet|DaemonSet)/ {print FILENAME}' {} +`
sed -i 's<strong i="19">@apiVersion</strong>: apps/v1beta2<strong i="20">@apiVersion</strong>: apps/v1@' `find . -iregex ".*yaml\|.*yml" -exec awk '/kind:\s+(Deployment|StatefulSet|ReplicaSet|DaemonSet)/ {print FILENAME}' {} +`

قم بإنشاء حزمة جديدة:

helm package ./prometheus
Successfully packaged chart and saved it to: /home/vagrant/charts/stable/prometheus-9.1.1.tgz

قم بتثبيته:
helm install /home/vagrant/charts/stable/prometheus-9.1.1.tgz

بناءً على https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/

ملاحظة: بالنسبة لبعض المخططات ذات التبعيات ، قد تحتاج إلى استخدام helm dependency update واستبدال tgz التابع بأخرى مصححة إذا كان ذلك ممكنًا.

الحصول على نفس الخطأ عند تشغيل helm init --history-max 200

انتاج

$HELM_HOME has been configured at /Users/neil/.helm.
Error: error installing: the server could not find the requested resource
$ helm version
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
Error: could not find tiller

هذا الفرع يعمل https://github.com/keleustes/helm/tree/kube16. يمكنك بناء الفرع بنفسك. لقد قمت أيضًا بتحميل الملف الثنائي هنا لراحتك https://s3-us-west-2.amazonaws.com/bin.cryptexlabs.com/github.com/keleustes/helm/kube16/darwin/helm. أحد التحذيرات هو أنه يجب عليك استخدام علامة صورة الكناري helm init --canary-image نظرًا لأن الإصدار لم يتم طرحه

لا تحتاج إلى صورة الكناري لإنجاز هذا العمل. أود أن أقترح استخدام helm init --tiller-image gcr.io/kubernetes-helm/tiller:v2.14.3 كما ذكر jbrette سابقًا إذا كنت تريد تجربة # 6462.

أوصي المستخدمين بتجربة أحد الحلول المقدمة مسبقًا أولاً قبل تجربة العلاقات العامة على أي حال ؛ بهذه الطريقة ، يمكنهم الاستمرار في استخدام Helm 2.14.3 بدلاً من فرع التطوير المخصص الذي لا يزال قيد المراجعة.

عندما أقوم بتنفيذ الأمر ، يتم نشره ولكن بعد ذلك يمكنه رؤيته في البودات ويقول خطأ من الخادم (NotFound): لم يتم العثور على البودات "تيلر-نشر"

helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="7">@apiVersion</strong>: extensions/v1beta1<strong i="8">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

publish.apps / الحارث-النشر تم إنشاؤه
تم إنشاء الخدمة / الحراثة

ولكن عندما أفعل kubectl أحصل على قرون - لا تستطيع جميع مساحات الأسماء رؤية القرون
اسم NAMESPACE اسم الوضع الجاهز يعود إلى العمر
نظام kube-coredns-5644d7b6d9-559hw 1/1 يعمل 0 23h
نظام kube-coredns-5644d7b6d9-xcmjd 1/1 يعمل 0 23h
نظام kube etcd-fmp 1/1 يعمل 0 24 ساعة
نظام kube kube-apiserver-fmp 1/1 يعمل 0 24 ساعة
نظام kube-kube-controller-manager-fmp 1/1 يعمل 1 24 ساعة
نظام kube-flannel-ds-amd64-ffx2g 1/1 الجري 0 23 ساعة
نظام kube-proxy-lfvrz 1/1 يعمل 0 24 ساعة
نظام kube kube-Scheduler-fmp 1/1 يعمل 0 24 ساعة

kubectl الحصول على جميع مساحات الأسماء | آلة الحراثة grep
خدمة نظام kube / نشر الحراثة ClusterIP xxx44134 / TCP 2m52s
kube-system publish.apps / الحارث-النشر 0/1 0 0 2m54s
kube-system replicaset.apps / الحارث-النشر -77855d9dcf 1 0 0 2m54s

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

شكرا!

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

شكرا!

آسف ، أنا جديد لقد فكرت أن هذا سيبدأ. كيف أبدأ حساب خدمة الحارث؟

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

kubectl --namespace kube-system create sa tiller
kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller

تمت إضافة العلامة أدناه إلى خادم api (/etc/kubernetes/manifests/kube-apiserver.yaml) الذي أعاد تمكين واجهات برمجة التطبيقات التي تم إيقافها مؤقتًا.

--runtime-config = apps / v1beta1 = صحيح ، تطبيقات / v1beta2 = صحيح ، ملحقات / v1beta1 / daemonsets = صحيح ، ملحقات / v1beta1 / عمليات النشر = صحيح ، ملحقات / v1beta1 / مجموعات متماثلة = صحيح ، ملحقات / v1beta1 / networkpolicies = صحيح ، ملحقات / v1beta1 / podsecuritypolicies = صحيح

هذا ثابت الدفة v2

بالنسبة للأشخاص الذين يستخدمون نظام التشغيل windows ، تمكنا من تثبيت / ترقية أداة الحرث عبر بوويرشيل مثل:

$(helm init --output yaml) -replace "extensions/v1beta1","apps/v1"

إليك حل قصير المدى:

helm init --output yaml | sed 's<strong i="7">@apiVersion</strong>: extensions/v1beta1<strong i="8">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

في الواقع ، هذا ليس جيدًا بما يكفي. ما زلت أتلقى خطأ:

error validating data: ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec

يمكن تصحيح ذلك باستخدام:

/usr/local/bin/kubectl patch --local -oyaml -f - -p '{"spec":{"selector": {"app":"helm","name":"tiller"}}}'

بالنسبة لي ، فإن رقعة kubectl معلقة
لا توجد رسائل في ملف / var / log / syslog

حسابات الخدمة موجودة بالفعل

kubeflow @ masternode : ~ $ kubectl --namespace kube-system إنشاء سا تيلر
خطأ من الخادم (بالفعل موجود): serviceaccounts "الحارث" موجود بالفعل
kubeflow @ masternode : ~ $ kubectl قم بإنشاء حراثة ربط عنقودية - clusterrol الكتلة-admin --serviceaccount = kube- النظام: الحارث
خطأ من الخادم (بالفعل موجود): clusterrolebindings.rbac.authorization.k8s.io "الحارث" موجود بالفعل

هل تستطيع أن تنصحني من فضلك

تنفيذ ما يلي

تصدير PATH = $ PATH: / usr / local / bin
أي دفة
أي الحارث
تثبيت دفة \
- Name nFS-client-Providerer \
- ضبط nfs.server = 10.0.0.4 \
- ضبط nfs.path = / nfsroot \
- ضبط storageClass.name = nfs \
- ضبط storageClass.defaultClass = صحيح \
مستقر / nFS-client-Providerer

يعود مع

/ usr / local / bin / helm
/ usr / local / bin / الحارث
خطأ: لا يمكن العثور على الحارث

نقدر أي مساعدة لأن هذا هو الآن سدادة عرض

cyrilthank يبدو أن خطأ الحارث يرجع إلى عدم تشغيل نشر الحارث ، حاول تشغيل هذا الأمر لتثبيت الحارث:
helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="7">@apiVersion</strong>: extensions/v1beta1<strong i="8">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

يجب أن يعيد helm version -s إصدار الخادم (الحارث) إذا كان يعمل بشكل صحيح

شكرا لك سيدي.
لقد ساعدت في تمكيننا من متابعة kubeflow إلى الخطوة التالية

حسنًا الآن أعتقد أنني حصلت على هذه المشكلة
https://github.com/kubeflow/kubeflow/issues/4184
العودة كمانع

نقدر ذلك كثيرًا إذا كان بإمكانك المساعدة في تقديم المشورة حول كيفية الحصول على بعض المساعدة على https://github.com/kubeflow/kubeflow/issues/4184

cyrilthank جرب الخطوات المذكورة أعلاه: https://github.com/helm/helm/issues/6374#issuecomment -533853888
تحتاج إلى استبدال إصدارات api المهملة بالإصدارات الجديدة

kubeflow_workaround_and_error_traces.txt

شكرا لك سيدي على ردودك الصبور خاصة في إبقاء هذه القضية مفتوحة

آسف لهذا ولكن يبدو أنني أقوم بشيء خاطئ في خطوات الحل

نقدر ما إذا كان بإمكانك مراجعة الخطوات الواردة في الآثار المرفقة وتقديم المشورة لي بشأن ما أفعله بشكل خاطئ

cyrilthank ، تحتاج فقط إلى تشغيل أوامر sed ضد kubeflow yamls لاستبدال امتداد api القديم بالامتداد الجديد (لا حاجة لنشر بروميثيوس على الإطلاق). آسف إذا لم أعرب عن نفسي بشكل جيد بما فيه الكفاية.
الإصلاح هو استبدال extensions/v1beta1 بـ apps/v1 في kubeflow dpl yamls

آه لذلك قمت بعمل نسخة غبية :(

KFAPP الخاص بي = / nfsroot / kf-poc

ما زلت أتلقى بعض الرسائل والخطأ الأخير

هل يمكنك مساعدتي لأنني أعتمد عليك الآن للانتقال إلى الخطوة التالية في kubeflow

kubeflow_workaround_sed_and_error_traces.txt

cyrilthank ، تحتاج فقط إلى تشغيل أوامر sed ضد kubeflow yamls لاستبدال امتداد api القديم بالامتداد الجديد (لا داعي لنشر بروميثيوس على الإطلاق). آسف إذا لم أعرب عن نفسي بشكل جيد بما فيه الكفاية.
الإصلاح هو استبدال extensions/v1beta1 بـ apps/v1 في kubeflow dpl yamls

apps/v1beta2 أيضًا بـ apps/v1

https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/

شكرا جزيلا uniuuu لمساعدتكم
هل يمكنك من فضلك إخبارك بمكان / كيفية الحصول على ملفات yaml المشار إليها في https://github.com/helm/helm/files/3662328/kubeflow_workaround_sed_and_error_traces.txt

https://github.com/helm/helm/issues/6374#issuecomment -533840097
https://github.com/helm/helm/issues/6374#issuecomment -533185074

طلب منذ بعد إجراء تغييرات sed ، ما زلنا نواجه الأخطاء المشار إليها في

هل يمكن أن تنصح إذا كانت الخطوة

kubectl تحويل -f- إخراج- نسخة/

يحتاج إلى تنفيذه لكليجري كل ملف yaml في موقع KFAPP بما في ذلك .kache

إذا قمت بتطبيق الحل البديل المذكور أعلاه عند العمل مع helm init ، وما زلت تتلقى الخطأ التالي عند تجربة أشياء مثل helm version ، فذلك بسبب helm deployment لايمكن إيجاده.

Error: could not find tiller

تحتاج إلى تشغيل kubectl get events --all-namespaces | grep -i tiller لتعرف سبب عدم استعدادها.

على سبيل المثال ، مشكلتي هي ببساطة على النحو التالي ، لأنني لست بحاجة إلى serviceaccount "tiller" مع microk8s .

microk8s.kubectl get events --all-namespaces | grep -i tiller
kube-system    23m         Warning   FailedCreate                   replicaset/tiller-deploy-77855d9dcf            Error creating: pods "tiller-deploy-77855d9dcf-" is forbidden: error looking up service account kube-system/tiller: serviceaccount "tiller" not found

لذلك قمت بالعمل دون حساب الخدمة

- helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="20">@apiVersion</strong>: extensions/v1beta1<strong i="21">@apiVersion</strong>: apps/v1@' | kubectl apply -f -
+ helm init spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="22">@apiVersion</strong>: extensions/v1beta1<strong i="23">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

cyrilthank لقد أزلت تعليقك لأنه لا علاقة له بالمناقشة المعنية هنا. يرجى الاستمرار في المتابعة في kubeflow / kubeflow # 4184. شكرا!

helm init spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="6">@apiVersion</strong>: extensions/v1beta1<strong i="7">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

تصحيح طفيف

helm init --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="11">@apiVersion</strong>: extensions/v1beta1<strong i="12">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

+1

@ puww1010 لقد قمت للتو بإعادة توجيه الإخراج في ملف ، ثم استخدمت VIM لتغييره. الأوامر أدناه كمرجع.

# helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml
# vim helm-init.yaml
# kubectl apply -f helm-init.yaml

حاولت فعل هذا. بعد تحرير الملف في VIM ، أستخدم الأمر kubectl apply ، لكن لا يبدو أنه يفعل أي شيء. عندما أقوم بتشغيل helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml مرة أخرى أو helm init --output yaml ، لم يتم تطبيق التغييرات. أي واحد آخر تجربة هذا؟

إذا كنت ترغب في استخدام واحد أقل من ذلك :)
helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="7">@apiVersion</strong>: extensions/v1beta1<strong i="8">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

شكرا!

لقد قمت للتو بترقية k8s الخاصة بنا وواجهت هذه المشكلة واستخدمت الحل أعلاه. يقوم بإنشاء النشر ولكن فشل النسخ المتماثلة وهذا ما أحصل عليه من kubectl describe -n kube-system replicasets.apps tiller-deploy-77855d9dcf :

Events:
  Type     Reason        Age                 From                   Message
  ----     ------        ----                ----                   -------
  Warning  FailedCreate  41s (x14 over 82s)  replicaset-controller  Error creating: pods "tiller-deploy-77855d9dcf-" is forbidden: error looking up service account kube-system/tiller: serviceaccount "tiller" not found

أين يمكنني العثور على ملف yaml لإنشاء حساب الخدمة هذا؟

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

kubectl --namespace kube-system create sa tiller
kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller

هذا حل مشكلتي!

تم دمج 6462 وسيتوفر في الإصدار التالي (2.15.0). في الوقت الحالي ، لا تتردد في استخدام الحلول المقدمة أعلاه أو استخدام إصدار الكناري .

شكرا لكم جميعا!

لا تزال صورة Canary تنتج نفس الخطأ ما لم يكن بها هذا الدمج حتى الآن ،

@ puww1010 لقد قمت للتو بإعادة توجيه الإخراج في ملف ، ثم استخدمت VIM لتغييره. الأوامر أدناه كمرجع.

# helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml
# vim helm-init.yaml
# kubectl apply -f helm-init.yaml

حاولت فعل هذا. بعد تحرير الملف في VIM ، أستخدم الأمر kubectl apply ، لكن لا يبدو أنه يفعل أي شيء. عندما أقوم بتشغيل helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml مرة أخرى أو helm init --output yaml ، لم يتم تطبيق التغييرات. أي واحد آخر تجربة هذا؟

نعم ، يحدث لي أيضًا.

قد تحتاج إلى تغيير موقع الصورة إلى gcr.azk8s.cn/kubernetes-helm/tiller:v2.14.3 ويبدو أن موقع gcr.io محظور.

قد تحتاج إلى تغيير موقع الصورة إلى gcr.azk8s.cn/kubernetes-helm/iller : v2.14.3 يبدو أن موقع gcr.io محظور.

على الرغم من كونها مشكلة صالحة تمامًا ، إلا أن هذه المشكلة متعامدة قليلاً مع المشكلة الموجودة في هذه المشكلة ، إلا أن gcr.io محظور في الصين ، للأسف. راجع https://github.com/helm/charts/issues/14607 لمزيد من المعلومات.

تمكنا من حل هذه المشكلة من خلال إعادة إصدار kubernetes إلى 1.15.4

شكرا UmamaheshMaxwell لمشاركة هذا.

هل يمكنك مشاركة الخطوات التي استخدمتها للتراجع عن إصدار kubernetes؟

cyrilthank إذا كانت minikube ، minikube config set kubernetes-version v1.15.4

شكرا UmamaheshMaxwell لمشاركة هذا.

هل يمكنك مشاركة الخطوات التي استخدمتها للتراجع عن إصدار kubernetes؟

cyrilthank لقد استخدمنا أجهزة 1.15.4

  1. إعادة تعيين kubeadm
  2. sudo apt-get install kubelet = 1.15.4-00 kubectl = 1.15.4-00 kubeadm = 1.15.4-00
  3. sudo kubeadm init --pod-network-cidr = 10.244.10.0 / 16 --apiserver-advertise-address = xxxx --apiserver-cert-extra-sans = xxxx --kubernetes-version "1.15.4"

--pod-network-cidr=10.244.10.0/16 - الفانيلا
--apiserver-advertise-address=x.x.x.x - عنوان IP الخاص بجهازك الافتراضي (Master)
--apiserver-cert-extra-sans=x.x.x.x - IP العام لجهازك الظاهري (الرئيسي) (هذا مطلوب ، إذا كنت تحاول الوصول إلى سيدك من جهازك المحلي.

ملاحظة: اتبع الرابط أدناه لإعداد ملف kubeconfig لمجموعة Kubernetes ذاتية الاستضافة (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/)

اسمحوا لي أن أعرف إذا كان لديك أي أسئلة.

cyrilthank إذا كان minikube ، تعيين تكوين minikube kubernetes-version v1.15.4

شكرًا MrSimonEmms لي ليس سأضطر إلى UmamaheshMaxwell

شكرا UmamaheshMaxwell لمشاركة هذا.
هل يمكنك مشاركة الخطوات التي استخدمتها للتراجع عن إصدار kubernetes؟

cyrilthank ، لقد استخدمنا أجهزة

إعادة تعيين kubeadm
sudo apt-get install kubelet = 1.15.4-00 kubectl = 1.15.4-00 kubeadm = 1.15.4-00
sudo kubeadm init --pod-network-cidr = 10.244.10.0 / 16 --apiserver-advertise-address = xxxx --apiserver-cert-extra-sans = xxxx --kubernetes-version "1.15.4"

--pod-network-cidr = 10.244.10.0 / 16 - الفانيلا
--apiserver-advertise-address = xxxx - عنوان IP الخاص بجهازك الظاهري (Master)
--apiserver-cert-extra-sans = xxxx - IP العام لجهازك الظاهري (الرئيسي) (هذا مطلوب ، إذا كنت تحاول الوصول إلى سيدك من جهازك المحلي.
ملاحظة: اتبع الرابط أدناه لإعداد ملف kubeconfig لمجموعة Kubernetes ذاتية الاستضافة (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/)
اسمحوا لي أن أعرف إذا كان لديك أي أسئلة.

شكرًا UmamaheshMaxwell على رد المريض

لديّ إعداد kubernetes 1.16 موجود ، هل يمكنك من فضلك تأكيد ما إذا كان بإمكاني تجربة تشغيل هذه الخطوات؟

شكرا UmamaheshMaxwell لمشاركة هذا.
هل يمكنك مشاركة الخطوات التي استخدمتها للتراجع عن إصدار kubernetes؟
cyrilthank ، لقد استخدمنا أجهزة
إعادة تعيين kubeadm
sudo apt-get install kubelet = 1.15.4-00 kubectl = 1.15.4-00 kubeadm = 1.15.4-00
sudo kubeadm init --pod-network-cidr = 10.244.10.0 / 16 --apiserver-advertise-address = xxxx --apiserver-cert-extra-sans = xxxx --kubernetes-version "1.15.4"
--pod-network-cidr = 10.244.10.0 / 16 - الفانيلا
--apiserver-advertise-address = xxxx - عنوان IP الخاص بجهازك الظاهري (Master)
--apiserver-cert-extra-sans = xxxx - IP العام لجهازك الظاهري (الرئيسي) (هذا مطلوب ، إذا كنت تحاول الوصول إلى سيدك من جهازك المحلي.
ملاحظة: اتبع الرابط أدناه لإعداد ملف kubeconfig لمجموعة Kubernetes ذاتية الاستضافة (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/)
اسمحوا لي أن أعرف إذا كان لديك أي أسئلة.

شكرًا UmamaheshMaxwell على رد المريض

لديّ إعداد kubernetes 1.16 موجود ، هل يمكنك من فضلك تأكيد ما إذا كان بإمكاني تجربة تشغيل هذه الخطوات؟

نعم cyrilthank ، حتى لدينا kubernetes 1.16.1 ولكن كان علينا إرجاعه إلى 1.15.4 ، أدناه هو الرابط إذا كنت تريد إعداده من البداية.

إصدار نظام تشغيل VM's

Distributor ID: Ubuntu
Description:    Ubuntu 18.04.3 LTS
Release:    18.04
Codename:   bionic

تنظيف kuberenetes

kubeadm reset
sudo apt-get purge kubeadm kubectl kubelet kubernetes-cni kube*   
sudo apt-get autoremove  
sudo rm -rf ~/.kube

إعداد Kubernetes (_Both Master و Node_)
https://www.howtoforge.com/tutorial/how-to-install-kubernetes-on-ubuntu/
(من الأفضل لك أتمتة الخطوات المقترحة في الرابط أعلاه بقدر ما تستطيع ، لتوفير وقتك)

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

قد تحتاج إلى تغيير موقع الصورة إلى gcr.azk8s.cn/kubernetes-helm/iller : v2.14.3 يبدو أن موقع gcr.io محظور.

على الرغم من كونها مشكلة صالحة تمامًا ، إلا أن هذه المشكلة متعامدة قليلاً مع المشكلة الموجودة في هذه المشكلة ، إلا أن gcr.io محظور في الصين ، للأسف. راجع الدفة / الرسوم البيانية # 14607 لمزيد من المعلومات.

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

أتلقى الخطأ أيضًا:

$ helm init
$HELM_HOME has been configured at C:\Users\user\.helm.
Error: error installing: the server could not find the requested resource

أحاول حلًا مقترحًا في هذه المشكلة ، لا سيما هذه . ومع ذلك ، بعد تعديل ملف Tiller.yaml وفقًا لذلك ، لا يمكنني تحديث التكوين. أحاول تنفيذ الأمر التالي لتطبيق التغييرات / تحديث التكوين:

$ kubectl apply -f tiller.yaml
deployment.apps/tiller-deploy configured
service/tiller-deploy configured

ولكن بعد ذلك ، إذا ركضت:

$ helm init --output yaml > tiller2.yaml

يظهر ملف Tiller2.yaml:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  template:

في الأساس ، لا تنعكس التغييرات. لذلك أفترض أنني لا أقوم بتحديث التكوين بشكل صحيح. ما هي الطريقة الصحيحة للقيام بذلك؟


تحرير : تمكنت من تشغيله. أنا أستخدم Minikube ، ومن أجل تشغيله ، قمت أولاً بخفض إصدار Kubernetes إلى 1.15.4.

minikube delete
minikube start --kubernetes-version=1.15.4

بعد ذلك ، كنت أستخدم وكيلًا ، لذلك اضطررت إلى إضافة عنوان IP الخاص بـ Minikube إلى قائمة NO_PROXY: 192.168.99.101 في حالتي. انظر: https://minikube.sigs.k8s.io/docs/reference/networking/proxy/

ملاحظة: بعد إجراء المزيد من الاختبارات ، ربما لا يكون الرجوع إلى إصدار أقدم ضروريًا ، وربما كل ما كنت أفتقده هو خطوة NO_PROXY. لقد أضفت كل 192.168.99.0/24 و 192.168.39.0/24 و 10.96.0.0/12 إلى إعداد NO_PROXY ويبدو الآن أنه يعمل بشكل جيد.

helm init --service-accountILLer --override spec.selector.matchLabels.'name '='iller'، spec.selector.matchLabels.'app '=' helm '--output yaml | sed ' s @ apiVersion : extension / v1beta1 @ apiVersion : apps / v1 @' | kubectl تطبيق -f -

لقد عملت بالنسبة لي ، شكرا جزيلا لك

مع تطور Kubernetes API ، تتم إعادة تنظيم واجهات برمجة التطبيقات أو ترقيتها بشكل دوري. عندما تتطور واجهات برمجة التطبيقات ، يتم إهمال واجهة برمجة التطبيقات القديمة وإزالتها في النهاية.

سيتوقف الإصدار v1.16 عن تقديم إصدارات API المهملة التالية لصالح إصدارات API الأحدث والأكثر استقرارًا:

NetworkPolicy (in the extensions/v1beta1 API group)
    Migrate to use the networking.k8s.io/v1 API, available since v1.8. Existing persisted data can be retrieved/updated via the networking.k8s.io/v1 API.
PodSecurityPolicy (in the extensions/v1beta1 API group)
    Migrate to use the policy/v1beta1 API, available since v1.10. Existing persisted data can be retrieved/updated via the policy/v1beta1 API.
DaemonSet, Deployment, StatefulSet, and ReplicaSet (in the extensions/v1beta1 and apps/v1beta2 API groups)
    Migrate to use the apps/v1 API, available since v1.9. Existing persisted data can be retrieved/updated via the apps/v1 API.

سيتوقف الإصدار v1.20 عن تقديم إصدارات API المهملة التالية لصالح إصدارات API الأحدث والأكثر استقرارًا:

Ingress (in the extensions/v1beta1 API group)
    Migrate to use the networking.k8s.io/v1beta1 API, serving Ingress since v1.14. Existing persisted data can be retrieved/updated via the networking.k8s.io/v1beta1 API.

ما يجب القيام به

  • قم بتغيير ملفات YAML للإشارة إلى أحدث واجهات برمجة التطبيقات
  • قم بتحديث عمليات الدمج ووحدات التحكم المخصصة لاستدعاء أحدث واجهات برمجة التطبيقات
  • قم بتحديث أدوات الطرف الثالث (وحدات التحكم في الدخول وأنظمة التسليم المستمر) لاستدعاء واجهات برمجة التطبيقات الأحدث

تشير إلى :

بصفتي helm n00b الذي يستخدم minikube ، تمكنت من التغلب على هذه المشكلة من خلال تعيين إصدار kubernetes مثل:

$ minikube delete
$ minikube start --kubernetes-version=1.15.4

أتمنى أن يساعد!

PierreF لقد استخدمت الحل الخاص بك (https://github.com/helm/helm/issues/6374#issuecomment-533186177) مع k8s v1.16.1 و helm v2.15.0 ولا يعمل الحارث.

Readiness probe failed: Get http://10.238.128.95:44135/readiness: dial tcp 10.238.128.95:44135: connect: connection refused

@ joshprzybyszewski-wf لقد استخدمت الأمر التالي

minikube start --memory=16384 --cpus=4 --kubernetes-version=1.15.4
kubectl create -f istio-1.3.3/install/kubernetes/helm/helm-service-account.yaml
helm init --service-account tiller
helm install istio-1.3.3/install/kubernetes/helm/istio-init --name istio-init --namespace istio-system
helm install istio-1.3.3/install/kubernetes/helm/istio --name istio --namespace istio-system

والآن احصل على ،

Error: validation failed: [unable to recognize "": no matches for kind "DestinationRule" in version "networking.istio.io/v1alpha3", unable to recognize "": no matches for kind "DestinationRule" in version "networking.istio.io/v1alpha3", unable to recognize "": no matches for kind "attributemanifest" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "attributemanifest" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "handler" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "handler" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2"]

إليك حل قصير المدى:

helm init --output yaml | sed 's<strong i="7">@apiVersion</strong>: extensions/v1beta1<strong i="8">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

في الواقع ، هذا ليس جيدًا بما يكفي. ما زلت أتلقى خطأ:

error validating data: ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec

يمكن تصحيح ذلك باستخدام:

/usr/local/bin/kubectl patch --local -oyaml -f - -p '{"spec":{"selector": {"app":"helm","name":"tiller"}}}'

فاتك إضافة محدد المشاركات macthLabels .

تمت إعادة توجيهي إلى حل

error: error parsing STDIN: error converting YAML to JSON: yaml: line 11: mapping values are not allowed in this context

تم إصلاح هذا في Helm 2.16.0 .

تمت إعادة توجيهي إلى حل

error: error parsing STDIN: error converting YAML to JSON: yaml: line 11: mapping values are not allowed in this context

تحقق من ملفات yaml ، في معظم الحالات ، يحتوي السطر المشار إليه على {} أو [] ولا يزال يحتوي على أشياء أخرى محددة تحته والتي تسبب الخطأ. في معظم الحالات تكون المشكلة ضمن القيم yaml ، وإلا تحقق من قسم القوالب في الرسم البياني.

مجرد ملاحظة جانبية لحلPierreF و @ mihivagyok . هذه لم تنجح معي عندما أستخدم مستودعات خاصة.

$ helm repo add companyrepo https://companyrepo
Error: Couldn't load repositories file (/home/username/.helm/repository/repositories.yaml).

أعتقد أن هذا يحدث لأن helm init لا تعمل ، فقط تقوم بإنشاء ملف yaml. لقد أصلحت ذلك عن طريق تشغيل helm init -c كإضافة.

في k8s v1.16.6 ، تتطلب helm init otput المواصفات.

الحل البديل الحالي يبدو كالتالي:

helm init --output yaml> حراثة. yaml
وتحديث الحارث.

  • التغيير إلى التطبيقات / v1
  • أضف حقل المحدد
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
....

إنه يعمل ، نظرًا لأن kubernetes يغير تطبيقات apiVersion / v1 إلى النشر ، فهناك شيء واحد يجب تغييره وهو أننا بحاجة إلى إضافة محددات matchLabels للمواصفات

يمكن أن يكون الحل البديل الآخر هو استخدام helm 3 ، والذي لا يستخدم الحارث.

helm init --output yaml | sed ' s @ apiVersion : extension / v1beta1 @ apiVersion : apps / v1 @' | kubectl تطبيق -f -

مرحبًا ، أثناء محاولة ذلك ، أحصل على هذا:

jenkins @ jenkin : ~ / .kube $ helm init --output yaml | sed ' s @ apiVersion : extension / v1beta1 @ apiVersion : apps / v1 @' | kubectl تطبيق -f -

الأمر "kubectl" غير موجود ، ولكن يمكن تثبيته باستخدام:

المفاجئة تثبيت kubectl
الرجاء سؤال المسؤول الخاص بك.

@ jenkins @ jenkin : ~ / .kube $

إخراج helm version : v2.14.3
إخراج kubectl version : العميل: v1.15.3 ، الخادم: v1.16.0-rc.1
موفر / النظام الأساسي للسحابة (AKS ، GKE ، Minikube وما إلى ذلك): خدمة IBM Cloud Kubernetes

$ helm init --service-account tiller
$HELM_HOME has been configured at /Users/xxxx/.helm.
Error: error installing: the server could not find the requested resource

$ helm init --debug --service-account tiller
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
. 
.
.

يبدو أن helm تحاول إنشاء نشر tiller باستخدام: apiVersion: extensions/v1beta1
وفقًا لـ: https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16
لم يعد مدعومًا.

أتلقى هذا الخطأ: كيف يمكنني حله ؟؟؟

root @ jenkin : ~ # helm init - خدمة حساب الحارث
تم تكوين HELM_HOME $ في /root/.helm.
خطأ: خطأ في التثبيت: غير معروف (post publishments.extensions)
الجذر @ jenkin : ~ #

إليك حل قصير المدى:

helm init --output yaml | sed 's<strong i="7">@apiVersion</strong>: extensions/v1beta1<strong i="8">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

في الواقع ، هذا ليس جيدًا بما يكفي. ما زلت أتلقى خطأ:

error validating data: ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec

يمكن تصحيح ذلك باستخدام:

/usr/local/bin/kubectl patch --local -oyaml -f - -p '{"spec":{"selector": {"app":"helm","name":"tiller"}}}'

سأتعامل مع هذا الخطأ :

jenkins @ jenkin : ~ / .helm $ helm init --output yaml | sed ' s @ apiVersion : extension / v1beta1 @ apiVersion : apps / v1 @' | kubectl تطبيق -f -

الأمر "kubectl" غير موجود ، ولكن يمكن تثبيته باستخدام:

المفاجئة تثبيت kubectl
الرجاء سؤال المسؤول الخاص بك.

@ jenkins @ jenkin : ~ / .helm $

الحل البديل ، باستخدام jq :

helm init -o json | jq '(select(.apiVersion == "extensions/v1beta1") .apiVersion = "apps/v1")' | jq '(select(.kind == "Deployment") .spec.selector.matchLabels.app = "helm")' | jq '(select(.kind == "Deployment") .spec.selector.matchLabels.name = "tiller")' | kubectl create -f -

الحل البديل ، باستخدام jq :

helm init -o json | jq '(select(.apiVersion == "extensions/v1beta1") .apiVersion = "apps/v1")' | jq '(select(.kind == "Deployment") .spec.selector.matchLabels.app = "helm")' | jq '(select(.kind == "Deployment") .spec.selector.matchLabels.name = "tiller")' | kubectl create -f -

لا يمكنك تحديث المورد بـ kubectl create

ikarlashov سهل بما يكفي لاستبدال "إنشاء" بـ "تطبيق". يفترض الخط المفرد أعلاه أن الشخص لم يحاول إنشاء الموارد بعد.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات