Kubernetes: تجاهل إعدادات مهلة الإخلاء

تم إنشاؤها على ٢٧ فبراير ٢٠١٩  ·  15تعليقات  ·  مصدر: kubernetes/kubernetes

الرجاء استخدام هذا النموذج أثناء الإبلاغ عن خطأ وتقديم أكبر قدر ممكن من المعلومات. قد يؤدي عدم القيام بذلك إلى عدم معالجة الخطأ الخاص بك في الوقت المناسب. شكر! إذا كان الأمر يتعلق بالأمان ، فيرجى الكشف عنه بشكل خاص عبر https://kubernetes.io/security/

ما حدث : لقد قمت بتعديل إعدادات pod-eviction-timeout الخاصة بـ kube-controller-manager على العقدة الرئيسية (لتقليل مقدار الوقت قبل أن يقوم k8s بإعادة إنشاء الكبسولة في حالة فشل العقدة). القيمة الافتراضية هي 5 دقائق ، قمت بتكوينها لمدة 30 ثانية. باستخدام الأمر sudo docker ps --no-trunc | grep "kube-controller-manager" تحققت من تطبيق التعديل بنجاح:

kubeadmin<strong i="10">@nodetest21</strong>:~$ sudo docker ps --no-trunc | grep "kube-controller-manager"
387261c61ee9cebce50de2540e90b89e2bc710b4126a0c066ef41f0a1fb7cf38   sha256:0482f640093306a4de7073fde478cf3ca877b6fcc2c4957624dddb2d304daef5                         "kube-controller-manager --address=127.0.0.1 --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf --client-ca-file=/etc/kubernetes/pki/ca.crt --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt --cluster-signing-key-file=/etc/kubernetes/pki/ca.key --controllers=*,bootstrapsigner,tokencleaner --kubeconfig=/etc/kubernetes/controller-manager.conf --leader-elect=true --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --root-ca-file=/etc/kubernetes/pki/ca.crt --service-account-private-key-file=/etc/kubernetes/pki/sa.key --use-service-account-credentials=true --pod-eviction-timeout=30s"

قمت بتطبيق عملية نشر أساسية بنسختين متماثلتين:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
      - image: busybox
        command:
        - sleep
        - "3600"
        imagePullPolicy: IfNotPresent
        name: busybox
      restartPolicy: Always

تم إنشاء الكبسولة الأولى على عقدة العامل الأولى ، وتم إنشاء الكبسولة الثانية على عقدة العامل الثانية:

NAME         STATUS   ROLES    AGE   VERSION
nodetest21   Ready    master   34m   v1.13.3
nodetest22   Ready    <none>   31m   v1.13.3
nodetest23   Ready    <none>   30m   v1.13.3

NAMESPACE     NAME                                 READY   STATUS    RESTARTS   AGE   IP          NODE         NOMINATED NODE   READINESS GATES
default       busybox-74b487c57b-5s6g7             1/1     Running   0          13s   10.44.0.2   nodetest22   <none>           <none>
default       busybox-74b487c57b-6zdvv             1/1     Running   0          13s   10.36.0.1   nodetest23   <none>           <none>
kube-system   coredns-86c58d9df4-gmcjd             1/1     Running   0          34m   10.32.0.2   nodetest21   <none>           <none>
kube-system   coredns-86c58d9df4-wpffr             1/1     Running   0          34m   10.32.0.3   nodetest21   <none>           <none>
kube-system   etcd-nodetest21                      1/1     Running   0          33m   10.0.1.4    nodetest21   <none>           <none>
kube-system   kube-apiserver-nodetest21            1/1     Running   0          33m   10.0.1.4    nodetest21   <none>           <none>
kube-system   kube-controller-manager-nodetest21   1/1     Running   0          20m   10.0.1.4    nodetest21   <none>           <none>
kube-system   kube-proxy-6mcn8                     1/1     Running   1          31m   10.0.1.5    nodetest22   <none>           <none>
kube-system   kube-proxy-dhdqj                     1/1     Running   0          30m   10.0.1.6    nodetest23   <none>           <none>
kube-system   kube-proxy-vqjg8                     1/1     Running   0          34m   10.0.1.4    nodetest21   <none>           <none>
kube-system   kube-scheduler-nodetest21            1/1     Running   1          33m   10.0.1.4    nodetest21   <none>           <none>
kube-system   weave-net-9qls7                      2/2     Running   3          31m   10.0.1.5    nodetest22   <none>           <none>
kube-system   weave-net-h2cb6                      2/2     Running   0          33m   10.0.1.4    nodetest21   <none>           <none>
kube-system   weave-net-vkb62                      2/2     Running   0          30m   10.0.1.6    nodetest23   <none>           <none>

لاختبار طرد البود الصحيح ، قمت بإغلاق أول عقدة عاملة. بعد حوالي دقيقة واحدة ، تغيرت حالة العقدة العاملة الأولى إلى "NotReady" ، ثم
اضطررت إلى الانتظار +5 دقائق (وهي المهلة الافتراضية لإخلاء الجراب) حتى يتم إعادة إنشاء البود الموجود على العقدة التي تم إيقاف تشغيلها على العقدة الأخرى.

ما توقعت حدوثه :
بعد تقارير حالة العقدة "NotReady" ، يجب إعادة إنشاء الكبسولة على العقدة الأخرى بعد 30 ثانية بدلاً من ذلك إذا كانت 5 دقائق الافتراضية!

كيفية إعادة إنتاجه (بأقل قدر ممكن من الدقة والدقة) :
قم بإنشاء ثلاث عقد. قم بتهيئة Kubernetes على العقدة الأولى ( sudo kubeadm init ) ، قم بتطبيق المكون الإضافي للشبكة ( kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" ) ، ثم انضم إلى العقدتين الأخريين (مثل: kubeadm join 10.0.1.4:6443 --token xdx9y1.z7jc0j7c8g8lpjog --discovery-token-ca-cert-hash sha256:04ae8388f607755c14eed702a23fd47802d5512e092b08add57040a2ae0736ac ).
أضف معلمة pod-eviction-timeout إلى Kube Controller Manager على العقدة الرئيسية: sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml :

apiVersion: v1
kind: Pod
metadata:
  annotations:
    scheduler.alpha.kubernetes.io/critical-pod: ""
  creationTimestamp: null
  labels:
    component: kube-controller-manager
    tier: control-plane
  name: kube-controller-manager
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-controller-manager
    - --address=127.0.0.1
    - --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf
    - --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
    - --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
    - --controllers=*,bootstrapsigner,tokencleaner
    - --kubeconfig=/etc/kubernetes/controller-manager.conf
    - --leader-elect=true
    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
    - --root-ca-file=/etc/kubernetes/pki/ca.crt
    - --service-account-private-key-file=/etc/kubernetes/pki/sa.key
    - --use-service-account-credentials=true
    - --pod-eviction-timeout=30s

(تم قطع yaml ، يظهر هنا الجزء الأول المرتبط فقط).

تأكد من تطبيق الإعدادات:
sudo docker ps --no-trunc | grep "kube-controller-manager"

قم بتطبيق عملية نشر بنسختين متماثلتين ، وتحقق من إنشاء جراب واحد على العقدة العاملة الأولى ، وتم إنشاء جراب واحد على عقدة العامل الثانية.
أغلق إحدى العقد ، وتحقق من الوقت المنقضي بين الحدث ، عندما تبلغ العقدة عن "NotReady" وأعيد إنشاء الكبسولة.

أي شيء آخر نحن بحاجة إلى معرفته؟ :
أواجه نفس المشكلة في بيئة متعددة الماجستير أيضًا.

البيئة :

  • إصدار Kubernetes (استخدم kubectl version ): v1.13.3
    إصدار العميل: version.Info {Major: "1"، Minor: "13"، GitVersion: "v1.13.3"، GitCommit: "721bfa751924da8d1680787490c54b9179b1fed0"، GitTreeState: "clean"، BuildDate: "2019-02-01T20: 08: 12Z "، GoVersion:" go1.11.5 "، المترجم:" gc "، النظام الأساسي:" linux / amd64 "}
    إصدار الخادم: version.Info {Major: "1"، Minor: "13"، GitVersion: "v1.13.3"، GitCommit: "721bfa751924da8d1680787490c54b9179b1fed0"، GitTreeState: "clean"، BuildDate: "2019-02-01T20: 00: 57Z "، GoVersion:" go1.11.5 "، المترجم:" gc "، النظام الأساسي:" linux / amd64 "}
  • موفر السحابة أو تكوين الأجهزة: Azure VM
  • نظام التشغيل (على سبيل المثال: cat /etc/os-release ): NAME = "Ubuntu" VERSION = "16.04.5 LTS (Xenial Xerus)"
  • Kernel (على سبيل المثال uname -a ): Linux nodetest21 4.15.0-1037-azure # 39 ~ 16.04.1-Ubuntu SMP الثلاثاء 15 يناير 17:20:47 بالتوقيت العالمي المنسق 2019 x86_64 x86_64 x86_64 GNU / Linux
  • أدوات التثبيت:
  • آخرون: Docker v18.06.1-ce
kinbug siapps sinode
مصدر
picture danielloczi

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

شكرا لملاحظاتك ChiefAlexander!
كتبت هذا هو الوضع. لقد راجعت الكبسولات ، وتأكدت من وجود القيم الافتراضية المعينة لحجرة التسامح:

kubectl describe pod busybox-74b487c57b-95b6n | grep -i toleration -A 2
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s

لذلك قمت ببساطة بإضافة قيمي الخاصة إلى النشر:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      tolerations:
      - key: "node.kubernetes.io/unreachable"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      - key: "node.kubernetes.io/not-ready"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      containers:
      - image: busybox
        command:
        - sleep
        - "3600"
        imagePullPolicy: IfNotPresent
        name: busybox
      restartPolicy: Always

بعد تطبيق النشر في حالة فشل العقدة ، تتغير حالة العقدة إلى "NotReady" ، ثم يتم إعادة إنشاء البودات بعد ثانيتين.

لذلك لا يتعين علينا التعامل مع مهلة طرد البودات بعد الآن ، يمكن ضبط المهلة على أساس بود! رائع!

شكرا مرة أخرى لمساعدتكم!

picture danielloczi في ٢٨ فبراير ٢٠١٩
🎉6 🚀2 👍1

ال 15 كومينتر

@ kubernetes / sig-node-bugs
@ kubernetes / sig-apps-bugs

danielloczi picture danielloczi في ٢٧ فبراير ٢٠١٩

danielloczi : تكرار الإشارات لتشغيل الإشعار:
@ kubernetes / sig-node-bugs، @ kubernetes / sig-apps-bugs

ردًا على هذا :

@ kubernetes / sig-node-bugs
@ kubernetes / sig-apps-bugs

تعليمات للتفاعل معي باستخدام تعليقات العلاقات العامة متوفرة هنا . إذا كانت لديك أسئلة أو اقتراحات تتعلق بسلوكي ، فالرجاء رفع قضية ضد

k8s-ci-robot picture k8s-ci-robot في ٢٧ فبراير ٢٠١٩

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

في الإصدار 1.13 ، تمت ترقية ميزة TaintBasedEviction إلى الإصدار التجريبي وتمكينها افتراضيًا ، ومن ثم تتم إضافة الملوثات تلقائيًا بواسطة NodeController (أو kubelet) ويتم تعطيل المنطق العادي لطرد البودات من العقد استنادًا إلى Ready NodeCondition.

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

ChiefAlexander picture ChiefAlexander في ٢٧ فبراير ٢٠١٩
👍6

النظر في هذا أكثر. مع تعيين TaintBasedEvitions على صحيح ، يمكنك ضبط وقت إخلاء القرون ضمن المواصفات الخاصة به ضمن التفاوتات:
https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint -based-evissions
يتم تعيين القيم الافتراضية لهذه من قبل وحدة تحكم القبول: https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/admission/defaulttolerationseconds/admission.go#L34
يمكن تعيين هاتين العلامتين عبر kube-apiserver ويجب أن تحقق نفس التأثير.

ChiefAlexander picture ChiefAlexander في ٢٧ فبراير ٢٠١٩
👍6 
// Controller will not proactively sync node health, but will monitor node
// health signal updated from kubelet. There are 2 kinds of node healthiness
// signals: NodeStatus and NodeLease. NodeLease signal is generated only when
// NodeLease feature is enabled. If it doesn't receive update for this amount
// of time, it will start posting "NodeReady==ConditionUnknown". The amount of
// time before which Controller start evicting pods is controlled via flag
// 'pod-eviction-timeout'.
// Note: be cautious when changing the constant, it must work with
// nodeStatusUpdateFrequency in kubelet and renewInterval in NodeLease
// controller. The node health signal update frequency is the minimal of the
// two.
// There are several constraints:
// 1. nodeMonitorGracePeriod must be N times more than  the node health signal
//    update frequency, where N means number of retries allowed for kubelet to
//    post node status/lease. It is pointless to make nodeMonitorGracePeriod
//    be less than the node health signal update frequency, since there will
//    only be fresh values from Kubelet at an interval of node health signal
//    update frequency. The constant must be less than podEvictionTimeout.
// 2. nodeMonitorGracePeriod can't be too large for user experience - larger
//    value takes longer for user to see up-to-date node health.
liucimin picture liucimin في ٢٨ فبراير ٢٠١٩

شكرا لملاحظاتك ChiefAlexander!
كتبت هذا هو الوضع. لقد راجعت الكبسولات ، وتأكدت من وجود القيم الافتراضية المعينة لحجرة التسامح:

kubectl describe pod busybox-74b487c57b-95b6n | grep -i toleration -A 2
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s

لذلك قمت ببساطة بإضافة قيمي الخاصة إلى النشر:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      tolerations:
      - key: "node.kubernetes.io/unreachable"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      - key: "node.kubernetes.io/not-ready"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      containers:
      - image: busybox
        command:
        - sleep
        - "3600"
        imagePullPolicy: IfNotPresent
        name: busybox
      restartPolicy: Always

بعد تطبيق النشر في حالة فشل العقدة ، تتغير حالة العقدة إلى "NotReady" ، ثم يتم إعادة إنشاء البودات بعد ثانيتين.

لذلك لا يتعين علينا التعامل مع مهلة طرد البودات بعد الآن ، يمكن ضبط المهلة على أساس بود! رائع!

شكرا مرة أخرى لمساعدتكم!

danielloczi picture danielloczi في ٢٨ فبراير ٢٠١٩
🎉6 🚀2 👍1

danielloczi مرحبا danielloczi، كيف حل هذه المشكلة؟ أنا أيضا أواجه هذه القضية

nick0323 picture nick0323 في ١٠ يونيو ٢٠١٩

@ 323929 أعتقد أن danielloczi لا يهتم pod-eviction-timeout في kube-controller-manager ، لكنه يحلها باستخدام Taint based Evictions ， لقد اختبرت بـ Taint based Evictions ، لقد نجحت لي.

zdyxry picture zdyxry في ٢٥ يونيو ٢٠١٩

هذا صحيح: لقد بدأت ببساطة في استخدام Taint based Eviction .

danielloczi picture danielloczi في ٢٦ يونيو ٢٠١٩

هل من الممكن جعلها عالمية؟ لا أريد تمكين ذلك لكل تكوين جراب ، خاصةً أنني أستخدم الكثير من الأشياء المعدة من الدفة

kamilgregorczyk picture kamilgregorczyk في ٢ يناير ٢٠٢٠
👍4

+1 لإمكانية تكوينه لكل مجموعة. نادرًا ما يكون الضبط لكل جراب أو لكل عملية نشر مفيدًا: في معظم الحالات ، تكون القيمة العالمية العاقلة أكثر ملاءمة والقيمة الافتراضية الحالية البالغة 5 أمتار طويلة في كثير من الحالات.

يرجى إعادة فتح هذه المشكلة.

morgwai picture morgwai في ٨ فبراير ٢٠٢٠

أواجه نفس المشكلة ، هل هناك طريقة لعدم تمكين عمليات الإخلاء المستندة إلى Taint وأن مهلة طرد pod-eviction-timeout تعمل في الوضع العالمي؟

richardqa picture richardqa في ٧ مارس ٢٠٢٠

أواجه نفس المشكلة ، هل هناك طريقة لعدم تمكين عمليات الإخلاء المستندة إلى Taint وأن مهلة طرد pod-eviction-timeout تعمل في الوضع العالمي؟

أعتقد أنه يمكنك تهيئة طرد البود العالمي عبر apiserver: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
لم أحاول ذلك ، ولكن كما أرى ، هناك خيارات: - افتراضي - غير جاهز - تسامح - ثواني و - افتراضي - غير قابل للوصول - تسامح - ثواني.

hrbasic picture hrbasic في ٣٠ مارس ٢٠٢٠
👍1

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

enricovittorini picture enricovittorini في ١٣ أبريل ٢٠٢٠

المشكلة نفسها

pythonzm picture pythonzm في ١٥ أبريل ٢٠٢٠
هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

cooligc picture cooligc  ·  3تعليقات
Seb-Solon picture Seb-Solon  ·  3تعليقات
mml picture mml  ·  3تعليقات
tbchj picture tbchj  ·  3تعليقات
montanaflynn picture montanaflynn  ·  3تعليقات