Kubernetes: mengabaikan setelan pod-eviction-timeout

Dibuat pada 27 Feb 2019  ·  15Komentar  ·  Sumber: kubernetes/kubernetes

Silakan gunakan template ini saat melaporkan bug dan berikan info sebanyak mungkin. Tidak melakukannya dapat menyebabkan bug Anda tidak ditangani tepat waktu. Terima kasih! Jika masalahnya terkait keamanan, harap ungkapkan secara pribadi melalui https://kubernetes.io/security/

Apa yang terjadi : Saya memodifikasi pengaturan pod-eviction-timeout dari kube-controller-manager pada node master (untuk mengurangi jumlah waktu sebelum k8s membuat kembali pod jika terjadi kegagalan node). Nilai defaultnya adalah 5 menit, saya konfigurasikan 30 detik. Menggunakan perintah sudo docker ps --no-trunc | grep "kube-controller-manager" saya memeriksa bahwa modifikasi berhasil diterapkan:

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"

Saya menerapkan penerapan dasar dengan dua replika:

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

Pod pertama dibuat pada node pekerja pertama, pod kedua dibuat pada node pekerja kedua:

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>

Untuk menguji pengusiran pod yang benar, saya mematikan node pekerja pertama. Setelah ~ 1 menit status node pekerja pertama berubah menjadi "NotReady", lalu
Saya harus menunggu +5 menit (yang merupakan batas waktu penggusuran pod default) agar pod di node yang dimatikan dapat dibuat ulang di node lain.

Apa yang Anda harapkan terjadi :
Setelah status node melaporkan "NotReady", pod harus dibuat ulang di node lain setelah 30 detik, bukan jika default 5 menit!

Cara memperbanyaknya (seminimal dan setepat mungkin) :
Buat tiga node. Init Kubernetes di node pertama ( sudo kubeadm init ), terapkan plugin jaringan ( kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" ), lalu gabungkan dua node lainnya (seperti: kubeadm join 10.0.1.4:6443 --token xdx9y1.z7jc0j7c8g8lpjog --discovery-token-ca-cert-hash sha256:04ae8388f607755c14eed702a23fd47802d5512e092b08add57040a2ae0736ac ).
Tambahkan parameter pod-eviction-timeout ke Kube Controller Manager pada node master: 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 dipotong, hanya bagian pertama yang terkait yang ditampilkan di sini).

Periksa apakah pengaturan sudah diterapkan:
sudo docker ps --no-trunc | grep "kube-controller-manager"

Terapkan penerapan dengan dua replika, periksa apakah satu pod dibuat pada node pekerja pertama, pod kedua dibuat pada node pekerja kedua.
Matikan salah satu node, dan periksa waktu yang telah berlalu di antara peristiwa tersebut, saat node melaporkan "NotReady" dan pod dibuat ulang.

Ada hal lain yang perlu kami ketahui? :
Saya mengalami masalah yang sama di lingkungan multi-master juga.

Lingkungan :

  • Versi Kubernetes (gunakan kubectl version ): v1.13.3
    Versi Klien: version.Info {Major: "1", Minor: "13", GitVersion: "v1.13.3", GitCommit: "721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState: "clean", BuildDate: "2019-02-01T20: 08: 12Z ", GoVersion:" go1.11.5 ", Penyusun:" gc ", Platform:" linux / amd64 "}
    Versi Server: version.Info {Mayor: "1", Minor: "13", GitVersion: "v1.13.3", GitCommit: "721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState: "clean", BuildDate: "2019-02-01T20: 00: 57Z ", GoVersion:" go1.11.5 ", Penyusun:" gc ", Platform:" linux / amd64 "}
  • Penyedia cloud atau konfigurasi perangkat keras: Azure VM
  • OS (mis .: cat /etc/os-release ): NAME = "Ubuntu" VERSION = "16.04.5 LTS (Xenial Xerus)"
  • Kernel (misalnya uname -a ): Linux nodetest21 4.15.0-1037-azure # 39 ~ 16.04.1-Ubuntu SMP Sel 15 Jan 17:20:47 UTC 2019 x86_64 x86_64 x86_64 GNU / Linux
  • Instal alat:
  • Lainnya: Docker v18.06.1-ce
kinbug siapps sinode
Sumber
picture danielloczi

Komentar yang paling membantu

Terima kasih atas tanggapan Anda ChiefAlexander!
Itulah situasinya, tulis Anda. Saya memeriksa pod, dan yakin ada nilai default yang ditetapkan ke pod untuk toleransi:

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

Jadi saya hanya menambahkan nilai saya sendiri ke penerapan:

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

Setelah menerapkan penerapan jika terjadi kegagalan node, status node berubah menjadi "NotReady", kemudian pod dibuat ulang setelah 2 detik.

Jadi kita tidak perlu lagi berurusan dengan pengusiran-pod, batas waktu dapat diatur berdasarkan Pod! Keren!

Sekali lagi terima kasih atas bantuan Anda!

picture danielloczi pada 28 Feb 2019
🎉6 🚀2 👍1

Semua 15 komentar

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

danielloczi picture danielloczi pada 27 Feb 2019

@danielloczi : Mengulangi sebutan untuk memicu pemberitahuan:
@ kubernetes / sig-node-bugs, @ kubernetes / sig-apps-bugs

Menanggapi ini :

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

Instruksi untuk berinteraksi dengan saya menggunakan komentar PR tersedia di sini . Jika Anda memiliki pertanyaan atau saran terkait dengan perilaku saya, harap ajukan masalah ke kubernetes / test-infra repository.

k8s-ci-robot picture k8s-ci-robot pada 27 Feb 2019

Saya juga mengalami masalah ini saat menguji pengaturan batas waktu penggusuran lebih rendah. Setelah melihat-lihat hal ini untuk beberapa saat, saya menemukan bahwa penyebabnya adalah TaintBasedEvictions yang baru.

Di versi 1.13, fitur TaintBasedEvictions dipromosikan ke beta dan diaktifkan secara default, oleh karena itu taint secara otomatis ditambahkan oleh NodeController (atau kubelet) dan logika normal untuk mengeluarkan pod dari node berdasarkan Ready NodeCondition dinonaktifkan.

Menyetel flag fitur untuk ini ke false menyebabkan pod dikeluarkan seperti yang diharapkan. Saya belum meluangkan waktu untuk mencari melalui kode penggusuran berbasis noda tetapi saya akan menebak bahwa kami tidak menggunakan bendera batas waktu penggusuran di dalamnya.

ChiefAlexander picture ChiefAlexander pada 27 Feb 2019
👍6

Mempelajari ini lebih lanjut. Dengan TaintBasedEvictions disetel ke true, Anda dapat menyetel waktu penggusuran pod Anda dalam speknya di bawah toleransi:
https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint -based-evictions
Nilai default ini disetel oleh pengontrol masuk: https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/admission/defaulttolerationseconds/admission.go#L34
Kedua flag tersebut dapat diatur melalui kube-apiserver dan akan mencapai efek yang sama.

ChiefAlexander picture ChiefAlexander pada 27 Feb 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 picture liucimin pada 28 Feb 2019

Terima kasih atas tanggapan Anda ChiefAlexander!
Itulah situasinya, tulis Anda. Saya memeriksa pod, dan yakin ada nilai default yang ditetapkan ke pod untuk toleransi:

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

Jadi saya hanya menambahkan nilai saya sendiri ke penerapan:

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

Setelah menerapkan penerapan jika terjadi kegagalan node, status node berubah menjadi "NotReady", kemudian pod dibuat ulang setelah 2 detik.

Jadi kita tidak perlu lagi berurusan dengan pengusiran-pod, batas waktu dapat diatur berdasarkan Pod! Keren!

Sekali lagi terima kasih atas bantuan Anda!

danielloczi picture danielloczi pada 28 Feb 2019
🎉6 🚀2 👍1

@danielloczi Hai danielloczi, Bagaimana Anda memperbaiki masalah ini? Saya juga menemui masalah ini

nick0323 picture nick0323 pada 10 Jun 2019

@ 323929 Saya pikir @danielloczi tidak peduli tentang parameter pod-eviction-timeout di kube-controller-manager, tetapi menyelesaikannya dengan menggunakan Taint based Evictions ， Saya menguji dengan Taint based Evictions , berhasil untuk saya.

zdyxry picture zdyxry pada 25 Jun 2019

Itu benar: Saya baru saja mulai menggunakan Taint based Eviction .

danielloczi picture danielloczi pada 26 Jun 2019

Apakah mungkin menjadikannya global? Saya tidak ingin mengaktifkannya untuk setiap konfigurasi pod, terutama karena saya menggunakan banyak hal yang sudah disiapkan dari helm

kamilgregorczyk picture kamilgregorczyk pada 2 Jan 2020
👍4

1 untuk memiliki kemungkinan untuk mengkonfigurasinya per seluruh cluster. penyetelan per pod atau per penerapan jarang berguna: dalam banyak kasus, nilai global yang waras jauh lebih nyaman dan default 5m saat ini terlalu panjang untuk banyak kasus.

tolong buka kembali masalah ini.

morgwai picture morgwai pada 8 Feb 2020

Saya menghadapi masalah yang sama, Apakah ada cara untuk Evictions berbasis Taint yang tidak dapat diaktifkan dan pod-eviction-timeout berfungsi dalam mode global?

richardqa picture richardqa pada 7 Mar 2020

Saya menghadapi masalah yang sama, Apakah ada cara untuk Evictions berbasis Taint yang tidak dapat diaktifkan dan pod-eviction-timeout berfungsi dalam mode global?

Saya pikir Anda dapat mengonfigurasi penggusuran pod global melalui apiserver: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
Saya tidak mencoba ini, tetapi seperti yang saya lihat ada opsi: --default-not-ready-toleration-seconds dan --default-unreachable-toleration-seconds.

hrbasic picture hrbasic pada 30 Mar 2020
👍1

Mengapa bug ini ditandai sebagai ditutup? Tampaknya masalah asli belum terpecahkan, tetapi hanya dapat diselesaikan.
Tidak jelas bagi saya mengapa flag pod-eviction-timeout tidak berfungsi

enricovittorini picture enricovittorini pada 13 Apr 2020

masalah yang sama

pythonzm picture pythonzm pada 15 Apr 2020
Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

broady picture broady  ·  3Komentar
alexferl picture alexferl  ·  3Komentar
cooligc picture cooligc  ·  3Komentar
tbchj picture tbchj  ·  3Komentar
rhohubbuild picture rhohubbuild  ·  3Komentar