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

5분 분량

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 상태의 노드는 포드를 스케줄링할 수 없습니다.

보안 상태를 개선하기 위해 관리형 노드 그룹은 노드 역할의 Amazon 리소스 이름(ARN)에서 컨테이너 네트워크 인터페이스(CNI) 정책을 제거할 수 있습니다. 이 누락된 CNI 정책으로 인해 노드가 NoTReady 상태로 변경됩니다. 이 문제를 해결하려면 지침에 따라 aws-node DaemonSet에 대한 IRSA(서비스 계정에 대한 IAM 역할)를 설정합니다.

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

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

출력은 다음과 유사하게 표시됩니다.

$ kubectl get pods -n kube-system -o wideNAME                             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

출력을 검토합니다. 노드 상태가 정상이면 aws-node 및 kube-proxy 포드가 Running 상태입니다.
aws-node 또는 kube-proxy 포드가 나열되지 않으면 3단계로 건너뜁니다. aws-node 및 kube-proxy 포드는 DaemonSet에 의해 관리됩니다. 즉, 클러스터의 각 노드에는 하나의 aws-node 및 kube-proxy 포드가 실행되어야 합니다. 자세한 내용은 Kubernetes 웹 사이트의 DaemonSet을 참조하세요.

포드 중 하나가 Running 이외의 상태인 경우 다음 명령을 실행합니다.
```
$ kubectl describe pod yourPodName -n kube-system
```
aws-node 및 kube-proxy 포드 로그에서 추가 정보를 가져오려면 다음 명령을 실행합니다.
```
$ kubectl logs yourPodName -n kube-system
```
describe 출력의 로그 및 이벤트는 포드가 Running 상태가 아닌 이유를 표시할 수 있습니다. 노드를 Ready 상태로 변경하려면 aws-node 및 kube-proxy 포드 모두 해당 노드에서 Running 상태여야 합니다.

aws-node 및 kube-proxy 포드가 명령 출력에 나타나지 않는 경우 다음 명령을 실행합니다.

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

출력에서 포드를 시작할 수 없는 이유를 검색하세요.

참고: Amazon EKS 컨트롤 플레인 로그에서 포드를 스케줄링할 수 없는 이유에 대한 정보를 검색할 수도 있습니다.

aws-node 및 kube-proxy의 버전이 AWS 지침에 따라 클러스터 버전과 호환되는지 확인합니다. 예를 들어 다음 명령을 실행하여 포드 버전을 확인합니다.

$ 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 버전을 업데이트하려면 Amazon VPC CNI plugin for Kubernetes Amazon EKS 추가 기능 작업을 참조하세요. kube-proxy 버전을 업데이트하려면 Amazon EKS 클러스터의 Kubernetes 버전 업데이트의 4단계를 따르세요.

일부 시나리오에서는 노드가 Unknown 상태일 수 있습니다. 이는 노드의 kubelet이 노드의 올바른 상태를 컨트롤 플레인에 전달할 수 없다는 것을 의미합니다.

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

노드와 컨트롤 플레인 간의 네트워크 구성 확인

서브넷에 Amazon EKS 컨트롤 플레인과 워커 노드 간의 트래픽을 차단하는 네트워크 ACL(액세스 제어 목록) 규칙이 없는지 확인합니다.
컨트롤 플레인 및 노드의 보안 그룹이 최소 인바운드 및 아웃바운드 요구 사항을 준수하는지 확인합니다.
(선택 사항) 노드가 프록시를 사용하도록 구성된 경우 프록시가 API 서버 엔드포인트에 대한 트래픽을 허용하는지 확인합니다.

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

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

참고: 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com을 API 서버 엔드포인트로 바꿉니다.

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

kubelet의 상태 확인

SSH를 사용하여 영향을 받는 워커 노드에 연결합니다.
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 2023-12-04 08:57:33 UTC; 40s ago

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

$ sudo systemctl restart kubelet

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

SSH를 사용하여 워커 노드 중 하나에 연결합니다.

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

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

참고: us-east-1을 워커 노드가 위치한 AWS 리전으로 바꿉니다.

워커 노드 인스턴스 프로파일 및 ConfigMap 확인

워커 노드 인스턴스 프로파일에 권장 정책이 있는지 확인합니다.

워커 노드 인스턴스 역할이 aws-auth ConfigMap에 있는지 확인합니다. 컨피그맵을 확인하려면 다음 명령을 실행합니다.

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

ConfigMap에는 워커 노드 인스턴스 AWS Identity and Access Management(IAM) 역할에 대한 항목이 있어야 합니다. 예를 들면, 다음과 같습니다.

apiVersion: v1kind: 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

주제

컨테이너

태그

Amazon Elastic Kubernetes Service

언어

한국어