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"

두 개의 복제본이있는 기본 배포를 적용했습니다.

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"를보고 한 후 기본 5 분이면 대신 30 초 후에 다른 노드에서 포드를 다시 만들어야합니다!

재현 방법 (가능한 한 최소한으로 정확하게) :
세 개의 노드를 만듭니다. 첫 번째 노드 ( sudo kubeadm init )에서 Kubernetes를 초기화하고 네트워크 플러그인 ( 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 ).
마스터 노드의 Kube Controller Manager에 pod-eviction-timeout 매개 변수를 추가합니다. 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"

두 개의 복제본이있는 배치를 적용하고 첫 번째 작업자 노드에 하나의 팟 (Pod)이 작성되고 두 번째 작업자 노드에 두 번째가 작성되는지 확인하십시오.
노드 중 하나를 종료하고 노드가 "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 1 월 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을 처리 할 필요가 없습니다. 타임 아웃은 Pod 기준으로 설정할 수 있습니다! 멋있는!

도와 주셔서 다시 한 번 감사드립니다!

danielloczi 에 2019년 02월 28일

🎉6 🚀2 👍1

모든 15 댓글

@ kubernetes / sig-node-bugs
@ 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 기능이 베타로 승격되고 기본적으로 활성화되어 있으므로 Taint는 NodeController (또는 kubelet)에 의해 자동으로 추가되고 Ready NodeCondition을 기반으로 노드에서 포드를 제거하는 일반 논리가 비활성화됩니다.

이에 대한 기능 플래그를 false로 설정하면 pod가 예상대로 제거됩니다. 오염 기반 제거 코드를 검색하는 데 시간이 걸리지 않았지만이 제거 시간 초과 플래그를 사용하지 않는 것 같습니다.

ChiefAlexander 에 2019년 02월 27일

👍6

이것을 더 살펴보면. TaintBasedEvictions를 true로 설정하면 허용 범위에서 해당 사양 내에서 포드 제거 시간을 설정할 수 있습니다.
https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint -based-evictions
이들의 기본값은 승인 컨트롤러에 의해 설정됩니다 : https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/admission/defaulttolerationseconds/admission.go#L34
이 두 플래그는 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을 처리 할 필요가 없습니다. 타임 아웃은 Pod 기준으로 설정할 수 있습니다! 멋있는!

도와 주셔서 다시 한 번 감사드립니다!

danielloczi 에 2019년 02월 28일

🎉6 🚀2 👍1

@danielloczi 안녕하세요 danielloczi,이 문제를 어떻게 해결합니까? 나도이 문제를 만나

nick0323 에 2019년 06월 10일

@ 323929 @danielloczi 는 kube-controller-manager의 pod-eviction-timeout 매개 변수에 대해 신경 쓰지 않는다고 생각하지만 Taint based Evictions 를 사용하여 해결합니다 ， 저는 Taint based Evictions 테스트했습니다. 나를 위해.

zdyxry 에 2019년 06월 25일

맞습니다 : 저는 단순히 Taint based Eviction 를 사용하기 시작했습니다.

danielloczi 에 2019년 06월 26일

글로벌화가 가능합니까? 각 포드 구성에 대해 활성화하고 싶지 않습니다. 특히 helm에서 준비된 많은 것을 사용합니다.

kamilgregorczyk 에 2020년 01월 02일

👍4

전체 클러스터별로 구성 할 수있는 가능성에 +1합니다. 포드 또는 배포별로 조정하는 것은 거의 유용하지 않습니다. 대부분의 경우 정상적인 전역 값이 더 편리하고 현재 기본값 인 5m는 많은 경우에 길어집니다.

이 문제를 다시여십시오.

morgwai 에 2020년 02월 08일

나는 이와 동일한 문제에 직면하고 있습니다. Taint 기반 Evictions를 비활성화하는 방법이 있으며 pod-eviction-timeout이 전역 모드에서 작동합니까?

richardqa 에 2020년 03월 07일

나는 이와 동일한 문제에 직면하고 있습니다. Taint 기반 Evictions를 비활성화하는 방법이 있으며 pod-eviction-timeout이 전역 모드에서 작동합니까?

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 등급