노드 상태를 NotReady 또는 Unknown에서 Ready 상태로 변경하려면 어떻게 해야 합니까?

최종 업데이트 날짜: 2020년 8월 26일

Amazon Elastic Kubernetes Service(Amazon EKS) 작업자 노드가 NotReady 또는 Unknown 상태입니다. 작업자 노드를 다시 Ready 상태로 되돌리고 싶습니다.

간략한 설명

NotReady 또는 Unknown 상태인 노드에서는 포드를 예약할 수 없습니다. Ready 상태인 노드에서만 포드를 예약할 수 있습니다.

다음은 NotReady 또는 Unknown 상태의 노드를 해결하는 해결 방법입니다.

노드가 MemoryPressure, DiskPressure 또는 PIDPressure 상태인 경우 노드에서 추가 포드를 예약할 수 있도록 리소스를 관리해야 합니다. 노드가 NetworkUnavailable 상태인 경우 노드에서 네트워크를 올바르게 구성해야 합니다. 자세한 내용은 Kubernetes 설명서의 노드 상태를 참조하세요.

참고: 포드 제거 및 리소스 제한 관리에 대한 자세한 내용은 Kubernetes 설명서의 리소스 부족 처리 구성을 참조하세요.

​해결 방법

aws-node 및 kube-proxy 포드를 확인하여 노드가 NotReady 상태인 이유를 확인합니다.

NotReady 상태의 노드는 예약된 포드에 사용할 수 없습니다.

1.    aws-nodekube-proxy 포드의 상태를 확인하려면 다음 명령을 실행합니다.

$ kubectl get pods -n kube-system -o wide

2.    1단계의 출력을 검토하여 aws-nodekube-proxy 포드의 상태를 확인합니다.

참고: aws-nodekube-proxy 포드는 DaemonSet에서 관리하므로 클러스터의 각 노드에는 실행 중인 aws-node 1개와 kube-proxy 포드가 있어야 합니다. aws-node 또는 kube-proxy 포드가 나열되지 않으면 4단계로 건너뜁니다. 자세한 내용은 Kubernetes 설명서의 DaemonSet를 참조하세요.

노드 상태가 정상이면 aws-nodekube-proxy 포드가 Running 상태여야 합니다. 예:

$ kubectl get pods -n kube-system -o wide
NAME                             READY   STATUS    RESTARTS   AGE        IP              NODE
aws-node-qvqr2                   1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal
kube-proxy-292b4                 1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal

두 포드 중 하나가 Running 이외의 상태인 경우 다음 명령을 실행합니다.

$ kubectl describe pod yourPodName -n kube-system

3.    aws-nodekube-proxy 포드 로그에서 추가 정보를 가져오려면 다음 명령을 실행합니다.

$ kubectl logs yourPodName -n kube-system

설명 출력의 로그와 이벤트는 포드가 Running 상태가 아닌 이유를 보여줄 수 있습니다. 노드를 Ready 상태로 변경하려면 aws-nodekube-proxy 포드가 모두 해당 노드에서 Running이어야 합니다.

참고: 포드의 이름은 앞의 예제와 같이 aws-node-qvqr2kube-proxy-292b4와 다를 수 있습니다.

4.    1단계에서 명령을 실행한 후 aws-nodekube-proxy 포드가 나열되지 않으면 다음 명령을 실행합니다.

$ kubectl describe daemonset aws-node -n kube-system
$ kubectl describe daemonset kube-proxy -n kube-system

5.    4단계에서 실행한 명령의 출력을 검색하여 포드를 시작할 수 없는 이유를 확인합니다.

팁: Amazon EKS 제어 플레인 로그에서 포드를 예약할 수 없는 이유에 대한 정보를 검색할 수 있습니다.

6.    AWS 가이드라인을 참고하여 aws-nodekube-proxy의 버전이 클러스터 버전과 호환되는지 확인합니다. 예를 들어 다음의 명령을 실행하여 포드 버전을 확인할 수 있습니다.

$ kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
$ kubectl get daemonset kube-proxy --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'

참고: aws-node 버전을 업데이트하려면 Kubernetes 업그레이드를 위한 Amazon VPC CNI 플러그인을 참조하세요. kube-proxy 버전을 업데이트하려면 기존 클러스터 업데이트의 4단계를 수행합니다.

일부 시나리오에서는 노드가 Unknown 상태일 수 있습니다. 즉, 노드의 kubelet이 올바른 노드 상태로 제어 플레인과 통신할 수 없습니다.

Unknown 상태의 노드 문제를 해결하려면 다음 섹션의 단계를 완료하세요.

  • 노드와 제어 플레인 간의 네트워크 구성 확인
  • kubelet 상태 확인
  • Amazon EC2 API 엔드포인트에 연결할 수 있는지 확인

노드와 제어 플레인 간의 네트워크 구성 확인

1.    서브넷에 Amazon EKS 제어 플레인과 작업자 노드 간의 트래픽을 차단하는 네트워크 ACL(액세스 제어 목록) 규칙이 없는지 확인합니다.

2.    제어 플레인 및 노드의 보안 그룹이 최소 인바운드 및 아웃바운드 요구 사항을 준수하는지 확인합니다.

3.    (선택 사항) 노드가 프록시를 사용하도록 구성된 경우 프록시가 API 서버 엔드포인트에 대한 트래픽을 허용하는지 확인합니다.

4.    노드가 API 서버에 액세스할 수 있는지 확인하려면 작업자 노드 안에서 다음 netcat 명령을 실행합니다.

$ nc -vz 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443
Connection to 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443 port [tcp/https] succeeded!

중요: 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com을 API 서버 엔드포인트로 바꾸세요.

5.    인터넷 게이트웨이 또는 NAT 게이트웨이를 통해 API 서버 엔드포인트와의 통신이 허용되도록 라우팅 테이블이 올바르게 구성되었는지 확인합니다. 클러스터가 PrivateOnly 네트워킹을 사용하는 경우 VPC 엔드포인트가 올바르게 구성되었는지 확인합니다.

kubelet 상태 확인

1.    SSH를 사용하여 영향을 받는 작업자 노드에 연결합니다.

2.    kubelet 로그를 확인하려면 다음 명령을 실행합니다.

$ journalctl -u kubelet > kubelet.log

참고: kubelet.log 파일에는 노드 상태 문제의 근본 원인을 찾는 데 도움이 되는 kubelet 작업에 대한 정보가 포함되어 있습니다.

로그가 문제의 원인에 대한 정보를 제공하지 않는 경우 다음 명령을 실행하여 작업자 노드에서 kubelet의 상태를 확인합니다.

$ sudo systemctl status kubelet
  kubelet.service - Kubernetes Kubelet
   Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-eksclt.al2.conf
   Active: inactive (dead) since Wed 2019-12-04 08:57:33 UTC; 40s ago

kubelet이 Running 상태가 아닌 경우 다음 명령을 실행하여 kubelet을 다시 시작합니다.

$ sudo systemctl restart kubelet

Amazon EC2 API 엔드포인트에 연결할 수 있는지 확인

1.    SSH를 사용하여 작업자 노드 중 하나에 연결합니다.

2.    AWS 리전의 Amazon Elastic Compute Cloud(Amazon EC2) API 엔드포인트에 연결할 수 있는지 확인하려면 다음 명령을 실행합니다.

$ nc -vz ec2.<region>.amazonaws.com 443
Connection to ec2.us-east-1.amazonaws.com 443 port [tcp/https] succeeded!

중요: us-east-1을 작업자 노드가 위치한 AWS 리전으로 변경합니다.

작업자 노드 인스턴스 프로파일 및 ConfigMap 확인

1.    작업자 노드 인스턴스 프로파일에 권장 정책이 있는지 확인합니다.

2.    작업자 노드 인스턴스 역할이 aws-auth ConfigMap에 나와 있는지 확인합니다. ConfigMap을 확인하려면 다음 명령을 실행하세요.

$ kubectl get cm aws-auth -n kube-system -o yaml

ConfigMap은 작업자 노드 인스턴스 AWS Identity and Access Management(IAM) 역할에 대한 항목이 있어야 합니다. 예:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: <ARN of instance role (not instance profile)>
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

이 문서가 도움이 되었습니까?


결제 또는 기술 지원이 필요합니까?