Kubernetes: फली-बेदखली-टाइमआउट सेटिंग्स को अनदेखा कर दिया

को निर्मित 27 फ़र॰ 2019 · 15टिप्पणियाँ · स्रोत: kubernetes/kubernetes

बग की रिपोर्ट करते समय कृपया इस टेम्पलेट का उपयोग करें और यथासंभव अधिक जानकारी प्रदान करें। ऐसा न करने पर आपके बग को समय पर संबोधित नहीं किया जा सकता है। धन्यवाद! यदि मामला सुरक्षा से संबंधित है, तो कृपया इसे https://kubernetes.io/security/ के माध्यम से निजी रूप से बताएं

क्या हुआ : मैंने मास्टर नोड पर pod-eviction-timeout क्यूब-कंट्रोलर-मैनेजर की 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>

सही फली बेदखली का परीक्षण करने के लिए मैंने पहले श्रमिक नोड को बंद कर दिया। ~ 1 मिनट के बाद पहले कार्यकर्ता नोड की स्थिति "NotReady" में बदल गई, फिर
मुझे दूसरे नोड पर फिर से बनाए जाने वाले नोड पर पॉड के लिए +5 मिनट (जो डिफ़ॉल्ट पॉड एविक्शन टाइमआउट है) इंतजार करना पड़ा।

क्या होने की उम्मीद है :
नोड स्थिति "NotReady" की रिपोर्ट के बाद, पॉड 30 सेकंड के बाद दूसरे नोड पर फिर से बनाया जाना चाहिए बजाय अगर डिफ़ॉल्ट 5 मिनट!

इसे कैसे पुन: पेश करें (जितना संभव हो न्यूनतम और ठीक है) :
तीन नोड बनाएं। पहले नोड ( 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 )।
मास्टर नोड पर क्यूब नियंत्रक प्रबंधक के लिए फली-निष्कासन-टाइमआउट पैरामीटर जोड़ें: 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

(याम्ल को काट दिया गया है, केवल संबंधित पहला भाग यहां दिखाया गया है)।

जांचें कि सेटिंग लागू है:
sudo docker ps --no-trunc | grep "kube-controller-manager"

दो प्रतिकृतियों के साथ एक तैनाती लागू करें, जांचें कि एक पॉड पहले श्रमिक नोड पर बनाया गया है, दूसरा दूसरे कार्यकर्ता नोड पर बनाया गया है।
नोड्स में से एक को शट डाउन करें, और नोड के "नॉट्रेडी" और पॉड को फिर से बनाए जाने की रिपोर्ट के बीच, बीते समय की जांच करें।

हमें कुछ और जानना चाहिए? :
मैं मल्टी-मास्टर वातावरण में भी इसी मुद्दे का अनुभव करता हूं।

पर्यावरण :

कुबेरनेट्स संस्करण ( kubectl version ): v1.13.3
क्लाइंट संस्करण: version.Info {मेजर: "1", माइनर: "13", GitVersion: "v1.13.3", GitCommit: "721bfa751924da8d1680787490454b9179b1fed0", GitTreeState: "clean", 2019: 2019। 12Z ", GoVersion:" go1.11.5 ", संकलक:" gc ", प्लेटफ़ॉर्म:" linux / am6464 "}
सर्वर संस्करण: version.Info {मेजर: "1", माइनर: "13", GitVersion: "v1.13.3", GitCommit: "721bfa751924da8d1680787490454b9179b1fed0", GitTreeState: "clean", 2019: 2019। 57Z ", GoVersion:" go1.11.5 ", कंपाइलर:" gc ", प्लेटफ़ॉर्म:" linux / am6464 "}
क्लाउड प्रदाता या हार्डवेयर कॉन्फ़िगरेशन: Azure VM
OS (उदाहरण: cat /etc/os-release ): NAME = "उबंटू" संस्करण = "16.04.5 LTS (Xenial Xerus)"
कर्नेल (जैसे uname -a ): लिनक्स nodetest21 4.15.0-1037-azure # 39 ~ 16.04.1-Ubuntu SMP Tue 15 जनवरी 17:20:47 UTC 2019 x86_64 x86_64 x86_64 GNU / Linux
उपकरण स्थापित करें:
अन्य: डॉकर v18.06.1-ce

kinbug siapps sinode

स्रोत

danielloczi

सबसे उपयोगी टिप्पणी

आपकी प्रतिक्रिया के लिए धन्यवाद चीफ एलेक्जेंडर!
यही स्थिति है, आपने लिखा। मैंने पॉड्स की जाँच की, और सुनिश्चित करें कि डिफ़ॉल्ट के लिए फली को निर्दिष्ट मान हैं:

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" में बदल जाती है, फिर 2 सेकंड के बाद फिर से पॉड बनाए जाते हैं।

इसलिए हमें अब पॉड-इवेशन-टाइमआउट से निपटने की ज़रूरत नहीं है, पॉड के आधार पर टाइमआउट सेट किया जा सकता है! ठंडा!

आपकी सहायता के लिए एक बार फिर से धन्यवाद!

danielloczi 28 फ़र॰ 2019

🎉6 🚀2 👍1

सभी 15 टिप्पणियाँ

@ कुबेरनेट्स / सिग-नोड-बग्स
@ kubernetes / sig-apps-बग्स

danielloczi 27 फ़र॰ 2019

@danielloczi : एक अधिसूचना को ट्रिगर करने के लिए उल्लेख दोहराते हुए:
@ कुबेरनेट्स / सिग-नोड-बग्स, @ कुबेरनेट्स / सिग-एप्स-बग्स

के जवाब में यह :

@ Kubernetes / sig नोड-कीड़े
@ Kubernetes / sig-क्षुधा-कीड़े

पीआर टिप्पणियों का उपयोग करके मेरे साथ बातचीत करने के निर्देश यहां उपलब्ध कुबेरनेट्स / टेस्ट-इन्फ्रा रिपॉजिटरी के खिलाफ एक समस्या दर्ज करें।

k8s-ci-robot 27 फ़र॰ 2019

बेदखली टाइमआउट कम करते हुए परीक्षण करते समय मैं भी इस मुद्दे पर भाग गया। कुछ समय के लिए इस पर घूमने के बाद मुझे पता चला कि इसका कारण नया टेंटबेड ईविक्शन है।

संस्करण 1.13 में, TaintBasedEvictions फ़ीचर को बीटा में बढ़ावा दिया जाता है और डिफ़ॉल्ट रूप से सक्षम किया जाता है, इसलिए Todets स्वतः NodeController (या kubelet) द्वारा जोड़े जाते हैं और रेडी नोडकोड के आधार पर नोड्स के लिए पॉड्स को हटाने के लिए सामान्य तर्क अक्षम होता है।

इसके लिए फीचर फ्लैग को सेट करने के कारण झूठी पॉड्स को उम्मीद की तरह बेदखल कर दिया जाता है। मैंने टेंट आधारित बेदखली कोड के माध्यम से खोज करने के लिए समय नहीं लिया है, लेकिन मुझे लगता है कि हम इस निष्कासन टाइमआउट ध्वज का उपयोग नहीं कर रहे हैं।

ChiefAlexander 27 फ़र॰ 2019

👍6

इसे और देखना। TaintBasedEvictions सच करने के लिए सेट के साथ आप सहन के तहत अपनी कल्पना के भीतर अपने फली बेदखली समय सेट कर सकते हैं:
https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint -based-evictions
इनका डिफ़ॉल्ट मान प्रवेश नियंत्रक द्वारा निर्धारित किया जा रहा है: https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/admission/defaulttolerationseconds/pmission.go#L34
उन दो झंडों को क्यूब-अपीज़र के माध्यम से सेट किया जा सकता है और उन्हें समान प्रभाव प्राप्त करना चाहिए।

ChiefAlexander 27 फ़र॰ 2019

👍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 28 फ़र॰ 2019

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

आपकी सहायता के लिए एक बार फिर से धन्यवाद!

danielloczi 28 फ़र॰ 2019

🎉6 🚀2 👍1

@danielloczi हाय डैनियोलोकी, आप इस मुद्दे को कैसे ठीक करते हैं? मैं इस मुद्दे को भी पूरा करता हूं

nick0323 10 जून 2019

@ 323929 मुझे लगता है कि @danielloczi क्यूब-कंट्रोलर-मैनेजर में pod-eviction-timeout पैरामीटर के बारे में परवाह नहीं करता है, लेकिन Taint based Evictions का उपयोग करके इसे हल करता है, मैंने Taint based Evictions साथ परीक्षण किया है, यह काम किया है मेरे लिए।

zdyxry 25 जून 2019

यह सही है: मैंने बस Taint based Eviction का उपयोग करना शुरू किया।

danielloczi 26 जून 2019

क्या इसे वैश्विक बनाना संभव है? मैं प्रत्येक पॉड कॉन्फिगरेशन के लिए सक्षम नहीं करना चाहता, विशेष रूप से यह कि मैं हेल्म से बहुत सारी तैयार चीजों का उपयोग करता हूं

kamilgregorczyk 2 जन॰ 2020

👍4

+1 प्रति पूर्ण क्लस्टर में कॉन्फ़िगर करने की संभावना रखने के लिए। प्रति फली या प्रति तैनाती के लिए ट्यूनिंग शायद ही कभी उपयोगी है: ज्यादातर मामलों में एक समझदार वैश्विक मूल्य अधिक सुविधाजनक होता है और 5 मीटर का वर्तमान डिफ़ॉल्ट कई मामलों के लिए लंबे समय तक वाया होता है।

कृपया इस मुद्दे को फिर से खोलें।

morgwai 8 फ़र॰ 2020

मैं इसी समस्या का सामना कर रहा हूं, क्या टेन आधारित बेदखलियों को हटाने का कोई तरीका है और यह पॉड-बेदखली-टाइमआउट वैश्विक मोड में काम करता है?

richardqa 7 मार्च 2020

मैं इसी समस्या का सामना कर रहा हूं, क्या टेन आधारित बेदखलियों को हटाने का कोई तरीका है और यह पॉड-बेदखली-टाइमआउट वैश्विक मोड में काम करता है?

मुझे लगता है कि आप वैश्विक फली बेदखली को apiserver के माध्यम से कॉन्फ़िगर कर सकते हैं: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
मैंने यह कोशिश नहीं की, लेकिन जैसा कि मैं देख सकता हूं कि विकल्प हैं: --default-not-ready-toleration-seconds और --default-unreachable-toleration-seconds।

hrbasic 30 मार्च 2020

👍1

इस बग को बंद के रूप में चिह्नित क्यों किया गया था? ऐसा लगता है कि मूल मुद्दा हल नहीं है, लेकिन केवल काम-आस-पास है।
मेरे लिए यह स्पष्ट नहीं है कि फली-बेदखली-टाइमआउट ध्वज काम क्यों नहीं कर रहा है

enricovittorini 13 अप्रैल 2020

वही मुद्दा

pythonzm 15 अप्रैल 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Kubernetes: फली-बेदखली-टाइमआउट सेटिंग्स को अनदेखा कर दिया

सबसे उपयोगी टिप्पणी

सभी 15 टिप्पणियाँ

संबंधित मुद्दों