Kubernetes: pod-eviction-timeout設定を無視しました

作成日 2019年02月27日 · 15コメント · ソース: kubernetes/kubernetes

バグを報告する際はこのテンプレートを使用し、できるだけ多くの情報を提供してください。そうしないと、バグがタイムリーに対処されない可能性があります。ありがとう！問題がセキュリティ関連の場合は、https：//kubernetes.io/security/を介して非公開で開示してください

何が起こったのか：マスターノードのkube-controller-managerのpod-eviction-timeout設定を変更しました（ノードに障害が発生した場合に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"

2つのレプリカを使用して基本的な展開を適用しました。

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

最初のワーカーノードで作成された最初のポッド、2番目のワーカーノードで作成された2番目のポッド：

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」を報告した後、デフォルトの5分ではなく、30秒後に他のノードでポッドを再作成する必要があります。

それを再現する方法（可能な限り最小限かつ正確に） ：
3つのノードを作成します。最初のノード（ sudo kubeadm init ）でKubernetesを初期化し、ネットワークプラグイン（ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" ）を適用してから、他の2つのノード（ kubeadm join 10.0.1.4:6443 --token xdx9y1.z7jc0j7c8g8lpjog --discovery-token-ca-cert-hash sha256:04ae8388f607755c14eed702a23fd47802d5512e092b08add57040a2ae0736ac ）に参加します。
pod-eviction-timeoutパラメーターをマスターノードのKubeController 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"

2つのレプリカを使用してデプロイメントを適用し、1つのポッドが最初のワーカーノードに作成され、2番目のポッドが2番目のワーカーノードに作成されることを確認します。
ノードの1つをシャットダウンし、ノードが「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
OS（例： cat /etc/os-release ）：NAME = "Ubuntu" VERSION = "16.04.5 LTS（Xenial Xerus）"
カーネル（例： uname -a ）：Linux nodetest21 4.15.0-1037-azure＃39〜16.04.1-Ubuntu SMP Tue Jan 15 17:20:47 UTC 2019 x86_64 x86_64 x86_64 GNU / Linux
ツールのインストール：
その他：Docker v18.06.1-ce

kinbug siapps sinode

ソース

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」に変わり、2秒後にポッドが再作成されます。

したがって、pod-eviction-timeoutを処理する必要はなくなり、タイムアウトはポッドベースで設定できます。涼しい！

よろしくお願いします！

danielloczi 2019年02月28日

🎉6 🚀2 👍1

全てのコメント15件

@ kubernetes / sig-ノード-バグ
@ kubernetes / sig-apps-bugs

danielloczi 2019年02月27日

@danielloczi ：通知をトリガーするために言及を繰り返します：
@ kubernetes / sig-node-bugs、@ kubernetes / sig-apps-bugs

対応して、この：

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

PRコメントを使用して私とやり取りするための手順は、こちらから入手できkubernetes / test-infraリポジトリに対して問題を

k8s-ci-robot 2019年02月27日

また、エビクションタイムアウトを低く設定してテストしているときに、この問題が発生しました。しばらくこれを調べた後、原因は新しいTaintBasedEvictionsであることがわかりました。

バージョン1.13では、TaintBasedEvictions機能がベータ版にプロモートされ、デフォルトで有効になっているため、汚染はNodeController（またはkubelet）によって自動的に追加され、ReadyNodeConditionに基づいてノードからポッドを削除するための通常のロジックは無効になります。

これの機能フラグをfalseに設定すると、ポッドが予想どおりに削除されます。汚染ベースのエビクションコードを検索するのに時間がかかりませんでしたが、このエビクションタイムアウトフラグを使用していないと思います。

ChiefAlexander 2019年02月27日

👍6

これをもっと調べます。 TaintBasedEvictionsをtrueに設定すると、許容範囲内の仕様内でポッドのエビクション時間を設定できます。
https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint -based-evictions
これらのデフォルト値は、アドミッションコントローラーによって設定されています： //github.com/kubernetes/kubernetes/blob/master/plugin/pkg/admission/defaulttolerationseconds/admission.go#L34
これらの2つのフラグは、kube-apiserverを介して設定でき、同じ効果を実現するはずです。

ChiefAlexander 2019年02月27日

👍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 2019年02月28日

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秒後にポッドが再作成されます。

したがって、pod-eviction-timeoutを処理する必要はなくなり、タイムアウトはポッドベースで設定できます。涼しい！

よろしくお願いします！

danielloczi 2019年02月28日

🎉6 🚀2 👍1

@daniellocziこんにちはdanielloczi、この問題をどのように修正しますか？私もこの問題に会います

nick0323 2019年06月10日

323929 @私は@daniellocziは気にしないと思いますpod-eviction-timeoutパラメータKUBE-コントローラ・マネージャーではなく、使用して解き、それをTaint based Evictions 、私がテストしたTaint based Evictions 、それが働いています私のために。

zdyxry 2019年06月25日

そうです：私は単にTaint based Evictionを使い始めました。

danielloczi 2019年06月26日

グローバルにすることは可能ですか？ポッド構成ごとにこれを有効にしたくありません。特に、ヘルムから準備されたものをたくさん使用します。

kamilgregorczyk 2020年01月02日

👍4

クラスター全体ごとに構成できる可能性がある場合は+1。ポッドごとまたはデプロイメントごとの調整が役立つことはめったにありません。ほとんどの場合、正常なグローバル値の方が便利であり、現在のデフォルトの5mは多くの場合長いものです。

この号を再度開いてください。

morgwai 2020年02月08日

私はこれと同じ問題に直面しています。汚染ベースのエビクションを無効にする方法はありますか？ポッドエビクションタイムアウトはグローバルモードで機能しますか？

richardqa 2020年03月07日

私はこれと同じ問題に直面しています。汚染ベースのエビクションを無効にする方法はありますか？ポッドエビクションタイムアウトはグローバルモードで機能しますか？

apiserverを介してグローバルポッドエビクションを構成できると思います： https ：//kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
私はこれを試しませんでしたが、ご覧のとおり、-default-not-ready-toleration-secondsと--default-unreachable-toleration-secondsのオプションがあります。

hrbasic 2020年03月30日

👍1

このバグがクローズとしてマークされたのはなぜですか？元の問題は解決されていないように見えますが、回避策のみです。
pod-eviction-timeoutフラグが機能しない理由は私にはわかりません

enricovittorini 2020年04月13日

同じ問題

pythonzm 2020年04月15日

このページは役に立ちましたか？

0 / 5 - 0 評価

Kubernetes: pod-eviction-timeout設定を無視しました

最も参考になるコメント

全てのコメント15件

関連する問題