기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 하이브리드 배포 모범 사례 이 가이드에서는 EKS Hybrid Nodes 또는 EKS Anywhere를 사용하여 온프레미스 또는 엣지 환경에서 배포를 실행하는 방법에 대한 지침을 제공합니다. 현재 다음 주제에 대한 가이드를 게시했습니다. + [EKS 하이브리드 노드 및 네트워크 연결 해제 모범 사례](hybrid-nodes-network-disconnections.md) # EKS 하이브리드 노드 및 네트워크 연결 해제 EKS Hybrid Nodes 아키텍처는 자체 데이터 센터 또는 엣지 로케이션에서 로컬 Kubernetes 클러스터를 완전히 실행하는 데 익숙한 고객에게 새로운 아키텍처가 될 수 있습니다. EKS Hybrid Nodes를 사용하면 Kubernetes 컨트롤 플레인이 AWS 리전에서 실행되고 노드만 온프레미스에서 실행되어 Kubernetes 클러스터 아키텍처가 “확장” 또는 “확장”됩니다. 이로 인해 “노드가 Kubernetes 컨트롤 플레인에서 연결 해제되면 어떻게 되나요?”라는 일반적인 질문이 발생합니다. 이 가이드에서는 다음 주제를 검토하여 해당 질문에 답합니다. 각 애플리케이션은 종속성, 구성 및 환경에 따라 다르게 작동할 수 있으므로 네트워크 연결 해제를 통해 애플리케이션의 안정성과 신뢰성을 검증하는 것이 좋습니다. EKS Hybrid Nodes 및 자체 애플리케이션을 사용하여 네트워크 연결 해제를 테스트하기 위해 참조할 수 있는 테스트 설정, 절차 및 결과는 aws-samples/eks-hybrid-examples GitHub 리포지토리를 참조하세요. GitHub 리포지토리에는이 가이드에 설명된 동작을 검증하는 데 사용되는 테스트에 대한 추가 세부 정보도 포함되어 있습니다. + [네트워크 연결 해제를 통한 안정성 모범 사례](hybrid-nodes-network-disconnection-best-practices.md) + [네트워크 연결 해제를 통한 Kubernetes 포드 장애 조치 동작](hybrid-nodes-kubernetes-pod-failover.md) + [네트워크 연결 해제를 통한 애플리케이션 네트워크 트래픽](hybrid-nodes-app-network-traffic.md) + [네트워크 연결 해제를 통해 자격 증명 호스팅](hybrid-nodes-host-creds.md) # 네트워크 연결 해제를 통한 안정성 모범 사례 ## 고가용성 네트워킹 하이브리드 노드와 Kubernetes 컨트롤 플레인 간의 네트워크 연결 해제를 방지하는 가장 좋은 방법은 온프레미스 환경에서 AWS로 또는 AWS와 중복되고 복원력이 뛰어난 연결을 사용하는 것입니다. 이러한 솔루션으로 고가용성 하이브리드 네트워크를 설계하는 방법에 대한 자세한 내용은 [AWS Direct Connect Resiliency Toolkit](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) 및 [AWS Site-to-Site VPN 설명서를](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-redundant-connection.html) 참조하세요. ## 고가용성 애플리케이션 애플리케이션을 설계할 때는 장애 도메인과 다양한 유형의 중단의 영향을 고려하세요. Kubernetes는 노드, 영역 및 리전 도메인 간에 애플리케이션 복제본을 배포하고 유지 관리하는 기본 제공 메커니즘을 제공합니다. 이러한 메커니즘의 사용은 애플리케이션 아키텍처, 환경 및 가용성 요구 사항에 따라 달라집니다. 예를 들어, 상태 비저장 애플리케이션은 종종 여러 복제본과 함께 배포할 수 있으며 임의 호스트 및 인프라 용량 간에 이동할 수 있으며 노드 선택기 및 토폴로지 분산 제약 조건을 사용하여 여러 도메인에서 애플리케이션의 인스턴스를 실행할 수 있습니다. Kubernetes에서 복원력이 뛰어난 애플리케이션을 빌드하기 위한 애플리케이션 수준 기법에 대한 자세한 내용은 [EKS 모범 사례 가이드를](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/) 참조하세요. Kubernetes는 포드를 다른 노드로 이동할지 여부를 결정할 때 Kubernetes 컨트롤 플레인과 연결이 해제된 노드에 대한 영역 정보를 평가합니다. 영역의 모든 노드에 연결할 수 없는 경우 Kubernetes는 해당 영역의 노드에 대한 포드 제거를 취소합니다. 여러 데이터 센터 또는 물리적 위치에서 노드가 실행되는 배포가 있는 경우 데이터 센터 또는 물리적 위치에 따라 각 노드에 영역을 할당하는 것이 가장 좋습니다. 클라우드의 노드로 EKS를 실행하면이 영역 레이블이 AWS cloud-controller-manager에 의해 자동으로 적용됩니다. 그러나 cloud-controller-manager는 하이브리드 노드에서 사용되지 않으므로 kubelet 구성을 통해이 정보를 전달할 수 있습니다. 하이브리드 노드에 대한 노드 구성에서 영역을 구성하는 방법의 예는 다음과 같습니다. 하이브리드 노드 CLI()를 사용하여 하이브리드 노드를 클러스터에 연결하면 구성이 전달됩니다`nodeadm`. `topology.kubernetes.io/zone` 레이블에 대한 자세한 내용은 [Kubernetes 설명서를](https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone) 참조하세요. 하이브리드 노드 CLI에 대한 자세한 내용은 [Hybrid Nodes nodeadm 참조](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html)를 참조하세요. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster region: my-region kubelet: flags: - --node-labels=topology.kubernetes.io/zone=dc1 hybrid: ... ``` ## 네트워크 모니터링 하이브리드 연결에 AWS Direct Connect 또는 AWS Site-to-Site VPN을 사용하는 경우 CloudWatch 경보, 로그 및 지표를 활용하여 하이브리드 연결 상태를 관찰하고 문제를 진단할 수 있습니다. 자세한 내용은 [AWS Direct Connect 리소스 모니터링](https://docs.aws.amazon.com/directconnect/latest/UserGuide/monitoring-overview.html) 및 [AWS Site-to-Site VPN 연결 모니터링을 참조하세요](https://docs.aws.amazon.com/vpn/latest/s2svpn/monitoring-overview-vpn.html). 하이브리드 node-lifecycle-controller가 보고하는 `NodeNotReady` 이벤트에 대한 경보를 생성하는 것이 좋습니다. Controller Manager에 대해 EKS 컨트롤 플레인 로깅을 활성화하고 상태가 “NodeNotReady”인 “노드에 대한 상태 변경 이벤트 메시지 기록” 메시지에 대해 CloudWatch에서 지표 필터를 생성하여이 경보를 생성할 수 있습니다. 지표 필터를 생성한 후 원하는 임계값을 기반으로이 필터에 대한 경보를 생성할 수 있습니다. 자세한 내용은 [ CloudWatch 설명서의 로그에 대한 경보를 참조하세요](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html). Transit Gateway(TGW) 및 Virtual Private Gateway(VGW) 기본 제공 지표를 사용하여 TGW 또는 VGW로 들어오고 나가는 네트워크 트래픽을 관찰할 수 있습니다. 이러한 지표에 대한 경보를 생성하여 네트워크 트래픽이 정상 수준 아래로 떨어지는 시나리오를 감지하여 하이브리드 노드와 EKS 컨트롤 플레인 간의 잠재적 네트워크 문제를 나타낼 수 있습니다. TGW 및 VGW 지표는 다음 표에 설명되어 있습니다. | Gateway | 지표 | 설명 | | --- | --- | --- | | 전송 게이트웨이 | BytesIn | 연결에서 TGW가 수신한 바이트(EKS 컨트롤 플레인에서 하이브리드 노드로) | | 전송 게이트웨이 | BytesOut | TGW에서 연결로 전송된 바이트(하이브리드 노드에서 EKS 컨트롤 플레인으로) | | 가상 프라이빗 게이트웨이 | TunnelDataIn | 연결의 AWS 측에서 VPN 터널을 통해 고객 게이트웨이로 전송된 바이트(EKS 컨트롤 플레인에서 하이브리드 노드로) | | 가상 프라이빗 게이트웨이 | TunnelDataOut | 고객 게이트웨이에서 VPN 터널을 통해 연결의 AWS 측에서 수신된 바이트(하이브리드 노드에서 EKS 컨트롤 플레인으로) | 또한 [CloudWatch Network Monitor](https://aws.amazon.com/blogs/networking-and-content-delivery/monitor-hybrid-connectivity-with-amazon-cloudwatch-network-monitor/)를 사용하여 하이브리드 연결에 대한 심층적인 인사이트를 얻어 평균 복구 시간을 줄이고 네트워크 문제가 AWS 또는 환경에서 발생하는지 확인할 수 있습니다. CloudWatch Network Monitor를 사용하여 하이브리드 네트워크 연결의 패킷 손실 및 지연 시간을 시각화하고 알림 및 임계값을 설정한 다음 네트워크 성능을 개선하기 위한 조치를 취할 수 있습니다. 자세한 내용은 [ Amazon CloudWatch Network Monitor 사용을](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/what-is-network-monitor.html) 참조하세요. EKS는 클러스터 및 애플리케이션의 상태를 모니터링하기 위한 몇 가지 옵션을 제공합니다. 클러스터 상태의 경우 EKS 콘솔의 관찰성 대시보드를 사용하여 문제를 신속하게 감지, 해결 및 해결할 수 있습니다. 클러스터, 애플리케이션 및 인프라 모니터링에 Amazon Managed Service for Prometheus, AWS Distro for Open Telemetry(ADOT) 및 CloudWatch를 사용할 수도 있습니다. EKS 관찰성 옵션에 대한 자세한 내용은 [클러스터 성능 모니터링 및 로그 보기를 참조하세요](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html). ## 로컬 문제 해결 하이브리드 노드와 EKS 컨트롤 플레인 간의 네트워크 연결 해제에 대비하기 위해 보조 모니터링 및 로깅 백엔드를 설정하여 리전 AWS 서비스에 연결할 수 없을 때 애플리케이션의 관찰성을 유지할 수 있습니다. 예를 들어 지표와 로그를 여러 백엔드로 전송하도록 AWS Distro for Open Telemetry(ADOT) 수집기를 구성할 수 있습니다. CLI와 같은 로컬 도구를 사용하여 포드 및 컨테이너와 로컬로 상호 작용`crictl`하여 `kubectl` 또는 일반적으로 Kubernetes API 서버 엔드포인트를 쿼리하는 다른 Kubernetes API 호환 클라이언트를 대체할 수도 있습니다. 에 대한 자세한 내용은 cri-tools GitHub의 [`crictl` 설명서를](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md) `crictl`참조하세요. 다음은 몇 가지 유용한 `crictl` 명령입니다. 호스트에서 실행 중인 포드 나열: ``` crictl pods ``` 호스트에서 실행 중인 컨테이너 나열: ``` crictl ps ``` 호스트에서 실행 중인 이미지를 나열합니다. ``` crictl images ``` 호스트에서 실행 중인 컨테이너의 로그를 가져옵니다. ``` crictl logs CONTAINER_NAME ``` 호스트에서 실행 중인 포드의 통계를 가져옵니다. ``` crictl statsp ``` ## 애플리케이션 네트워크 트래픽 하이브리드 노드를 사용할 때는 애플리케이션 트래픽의 네트워크 흐름과 애플리케이션을 클러스터 외부에 노출하는 데 사용하는 기술을 고려하고 이해하는 것이 중요합니다. 애플리케이션 로드 밸런싱 및 수신을 위한 다양한 기술은 네트워크 연결 해제 중에 다르게 작동합니다. 예를 들어 애플리케이션 로드 밸런싱에 Cilium의 BGP 제어 플레인 기능을 사용하는 경우 네트워크 연결 해제 중에 포드 및 서비스에 대한 BGP 세션이 중단될 수 있습니다. 이는 BGP 스피커 기능이 Cilium 에이전트와 통합되고 Kubernetes 컨트롤 플레인에서 연결이 끊어지면 Cilium 에이전트가 계속 다시 시작되기 때문입니다. 재시작 이유는 상태가 Kubernetes 컨트롤 플레인에 대한 액세스와 결합되어 있기 때문에 Cilium의 상태 확인이 실패하기 때문입니다(Cilium v[1.17의 옵트인 개선이 적용된 CFP: \$131702](https://github.com/cilium/cilium/issues/31702) 참조). 마찬가지로 AWS 리전에서 시작된 애플리케이션 트래픽에 Application Load Balancer(ALB) 또는 Network Load Balancer(NLB)를 사용하는 경우 온프레미스 환경이 AWS 리전에 대한 연결을 끊으면 해당 트래픽이 일시적으로 중단될 수 있습니다. 프로덕션에 배포하기 전에 네트워크 연결 해제 중에 로드 밸런싱 및 수신에 사용하는 기술이 안정적으로 유지되는지 확인하는 것이 좋습니다. [aws-samples/eks-hybrid-examples](https://github.com/aws-samples/eks-hybrid-examples) GitHub 리포지토리의 예제는 [L2 모드에서](https://metallb.universe.tf/concepts/layer2/) 로드 밸런싱에 MetalLB를 사용하며, 이는 하이브리드 노드와 EKS 컨트롤 플레인 간의 네트워크 연결 해제 중에 안정적으로 유지됩니다. ## 원격 AWS 서비스에 대한 종속성 검토 하이브리드 노드를 사용할 때는 온프레미스 또는 엣지 환경 외부의 리전 AWS 서비스에 대해 수행하는 종속성을 알고 있어야 합니다. 예를 들어 애플리케이션 데이터에 Amazon S3 또는 Amazon RDS 액세스, 지표 및 로그에 Amazon Managed Service for Prometheus 또는 CloudWatch 사용, 리전에서 생성된 트래픽에 Application and Network Load Balancer 사용, Amazon Elastic Container Registry에서 컨테이너 가져오기 등이 있습니다. 온프레미스 환경과 AWS 간의 네트워크 연결 해제 중에는 이러한 서비스에 액세스할 수 없습니다. 온프레미스 환경에서 AWS와의 네트워크 연결이 끊기 쉬운 경우 AWS 서비스 사용을 검토하고 해당 서비스에 대한 연결이 끊어지더라도 애플리케이션의 정적 안정성이 손상되지 않는지 확인합니다. ## Kubernetes 포드 장애 조치 동작 조정 호스트 간에 이식할 수 없는 애플리케이션 또는 포드 장애 조치를 위한 예비 용량이 없는 리소스 제약 환경에서 네트워크 연결 해제 중에 포드 장애 조치 동작을 조정할 수 있는 옵션이 있습니다. 일반적으로 애플리케이션의 리소스 요구 사항을 고려하고 노드에 장애가 발생할 경우 하나 이상의 애플리케이션 인스턴스가 다른 호스트로 장애 조치할 수 있는 충분한 용량을 확보하는 것이 중요합니다. + 옵션 1 - DaemonSets 사용:이 옵션은 클러스터의 모든 노드에서 실행될 수 있고 실행되어야 하는 애플리케이션에 적용됩니다. DaemonSets는 연결할 수 없는 테인트를 허용하도록 자동으로 구성되므로 DaemonSet 포드가 네트워크 연결 해제를 통해 노드에 바인딩됩니다. + 옵션 2 - 연결할 수 없는 테인트에 `tolerationSeconds` 맞게 조정: 네트워크 연결 해제 중에 포드가 노드에 바인딩된 상태로 유지되는 시간을 조정할 수 있습니다. 이렇게 하려면 지정한 기간(`tolerationSeconds`애플리케이션 사양의 ) 동안 `NoExecute` 효과로 연결할 수 없는 테인트를 허용하도록 애플리케이션 포드를 구성합니다. 이 옵션을 사용하면 네트워크 연결이 끊어지면 애플리케이션 포드가 `tolerationSeconds` 만료될 때까지 노드에 바인딩된 상태로 유지됩니다. `tolerationSeconds`를 사용하여 연결할 수 없는 테인트를 늘리`NoExecute`면 연결할 수 없는 호스트에서 실행되는 포드가 다른 연결 가능한 정상 호스트로 이동하는 데 시간이 더 오래 걸릴 수 있으므로 신중하게 고려하세요. + 옵션 3: 사용자 지정 컨트롤러: `NoExecute` 효과로 연결할 수 없는 테인트에 대해 Kubernetes를 모니터링하는 사용자 지정 컨트롤러(또는 기타 소프트웨어)를 생성하고 실행할 수 있습니다. 이 테인트가 감지되면 사용자 지정 컨트롤러는 애플리케이션별 지표를 확인하여 애플리케이션 상태를 평가할 수 있습니다. 애플리케이션이 정상인 경우 사용자 지정 컨트롤러는 연결할 수 없는 테인트를 제거하여 네트워크 연결 해제 중에 노드에서 포드가 제거되지 않도록 할 수 있습니다. 다음은 연결할 수 없는 테인트에 `tolerationSeconds` 대해를 사용하여 배포를 구성하는 방법의 예입니다. 이 예에서 `tolerationSeconds`는 `1800` (30분)로 설정되어 있습니다. 즉, 네트워크 연결 해제가 30분 이상 지속되는 경우에만 연결할 수 없는 노드에서 실행되는 포드가 제거됩니다. ``` apiVersion: apps/v1 kind: Deployment metadata: ... spec: ... tolerations: - key: "node.kubernetes.io/unreachable" operator: "Exists" effect: "NoExecute" tolerationSeconds: 1800 ``` # 네트워크 연결 해제를 통한 Kubernetes 포드 장애 조치 먼저 노드와 Kubernetes 컨트롤 플레인 간의 네트워크 연결 해제 중에 Kubernetes가 작동하는 방식에 영향을 미치는 주요 개념, 구성 요소 및 설정을 검토합니다. EKS는 업스트림 Kubernetes 규정을 준수하므로 여기에 설명된 모든 Kubernetes 개념, 구성 요소 및 설정이 EKS 및 EKS Hybrid Nodes 배포에 적용됩니다. 네트워크 연결 해제 중 포드 장애 조치 동작을 개선하기 위해 특히 EKS가 개선되었습니다. 자세한 내용은 업스트림 Kubernetes 리포지토리의 GitHub 문제 [\$1131294](https://github.com/kubernetes/kubernetes/pull/131294) 및 [\$1131481](https://github.com/kubernetes/kubernetes/issues/131481)을 참조하세요. ## 개념 테인트 및 허용치: 테인트 및 허용치는 Kubernetes에서 노드에 대한 포드 예약을 제어하는 데 사용됩니다. 테인트는 node-lifecycle-controller에 의해 설정되어 노드가 예약에 적합하지 않거나 해당 노드의 포드를 제거해야 함을 나타냅니다. 네트워크 연결 해제로 인해 노드에 연결할 수 없는 경우 node-lifecycle-controller는 NoSchedule 효과와 특정 조건이 충족되면 NoExecute 효과와 함께 node.kubernetes.io/unreachable 테인트를 적용합니다. node.kubernetes.io/unreachable 테인은 NodeCondition Ready 알 수 없음에 해당합니다. 사용자는 PodSpec의 애플리케이션 수준에서 테인트에 대한 허용치를 지정할 수 있습니다. + NoSchedule: 일치하는 허용 오차가 없는 한 테인트된 노드에 새 포드가 예약되지 않습니다. 노드에서 이미 실행 중인 포드는 제거되지 않습니다. + NoExecute: 테인트를 허용하지 않는 포드는 즉시 제거됩니다. 테인트를 허용하는 포드(tolerationSeconds를 지정하지 않음)는 영구적으로 바인딩됩니다. 지정된 tolerationSeconds로 테인트를 허용하는 포드는 지정된 시간 동안 바인딩된 상태로 유지됩니다. 이 시간이 경과하면 노드 수명 주기 컨트롤러는 노드에서 포드를 제거합니다. 노드 임대: Kubernetes는 임대 API를 사용하여 Kubernetes API 서버에 kubelet 노드 하트비트를 전달합니다. 모든 노드에는 일치하는 이름을 가진 임대 객체가 있습니다. 내부적으로 각 kubelet 하트비트는 리스 객체의 spec.renewTime 필드를 업데이트합니다. Kubernetes 컨트롤 플레인은이 필드의 타임스탬프를 사용하여 노드 가용성을 결정합니다. 노드가 Kubernetes 컨트롤 플레인에서 연결 해제된 경우 리스에 대한 spec.renewTime을 업데이트할 수 없으며 컨트롤 플레인은 이를 NodeCondition Ready를 알 수 없음으로 해석합니다. ## 구성 요소 ![\[포드 장애 조치 동작과 관련된 Kubernetes 구성 요소\]](http://docs.aws.amazon.com/ko_kr/eks/latest/best-practices/images/hybrid/k8s-components-pod-failover.png) | 구성 요소 | 하위 구성 요소 | 설명 | | --- | --- | --- | | Kubernetes 컨트롤 플레인 | kube-api-server | API 서버는 Kubernetes API를 노출하는 Kubernetes 컨트롤 플레인의 핵심 구성 요소입니다. | | Kubernetes 컨트롤 플레인 | node-lifecycle-controller | kube-controller-manager가 실행하는 컨트롤러 중 하나입니다. 노드 문제를 감지하고 대응할 책임이 있습니다. | | Kubernetes 컨트롤 플레인 | kube-scheduler | 노드가 할당되지 않은 새로 생성된 포드를 감시하고 실행할 노드를 선택하는 컨트롤 플레인 구성 요소입니다. | | Kubernetes 노드 | kubelet | 클러스터의 각 노드에서 실행되는 에이전트입니다. kubelet은 PodSpecs를 감시하고 해당 PodSpecs에 설명된 컨테이너가 실행 중이고 정상인지 확인합니다. | ## 구성 설정 | 구성 요소 | 설정 | 설명 | K8s 기본값 | EKS 기본값 | EKS에서 구성 가능 | | --- | --- | --- | --- | --- | --- | | kube-api-server | default-unreachable-toleration-seconds | 이러한 허용치`unreachable:NoExecute`가 아직 없는 모든 포드에 기본적으로 추가되는 `tolerationSeconds`에 대한 허용치의를 나타냅니다. | 300 | 300 | 아니요 | | node-lifecycle-controller | node-monitor-grace-period | 비정상으로 표시되기 전에 노드가 응답하지 않을 수 있는 시간입니다. kubelet의 보다 N배여야 합니다. `nodeStatusUpdateFrequency`여기서 N은 kubelet이 노드 상태를 게시하는 데 허용되는 재시도 횟수입니다. | 40 | 40 | 아니요 | | node-lifecycle-controller | large-cluster-size-threshold | 노드 node-lifecycle-controller 처리하는 노드 수입니다. `--secondary-node-eviction-rate`는이 크기 이하의 클러스터의 경우 0으로 재정의됩니다. | 50 | 100,000건 | 아니요 | | node-lifecycle-controller | unhealthy-zone-threshold | 해당 영역이 비정상으로 처리되려면 준비되지 않음이어야 하는 영역의 노드 비율입니다. | 55% | 55% | 아니요 | | kubelet | node-status-update-frequency | kubelet이 컨트롤 플레인에 노드 상태를 게시하는 빈도입니다. node-lifecycle-controller`nodeMonitorGracePeriod`에서와 호환되어야 합니다. | 10 | 10 | 예 | | kubelet | 노드 레이블 | 클러스터에 노드를 등록할 때 추가할 레이블입니다. 하이브리드 노드로 레이블을 지정하여 노드를 영역으로 그룹화할 `topology.kubernetes.io/zone` 수 있습니다. | 없음 | 없음 | 예 | ## 네트워크 연결 해제를 통한 Kubernetes 포드 장애 조치 여기에 설명된 동작은 포드가 기본 설정으로 Kubernetes 배포로 실행되고 EKS가 Kubernetes 공급자로 사용된다고 가정합니다. 실제 동작은 환경, 네트워크 연결 해제 유형, 애플리케이션, 종속성 및 클러스터 구성에 따라 다를 수 있습니다. 이 가이드의 내용은 특정 애플리케이션, 클러스터 구성 및 플러그인의 하위 집합을 사용하여 검증되었습니다. 프로덕션으로 전환하기 전에 자체 환경과 자체 애플리케이션에서 동작을 테스트하는 것이 좋습니다. 노드와 Kubernetes 컨트롤 플레인 간에 네트워크 연결이 끊어지면 연결이 끊긴 각 노드의 kubelet이 Kubernetes 컨트롤 플레인과 통신할 수 없습니다. 따라서 연결이 복원될 때까지 kubelet이 해당 노드에서 포드를 제거할 수 없습니다. 즉, 네트워크 연결 해제 전에 해당 노드에서 실행되는 포드는 연결 해제 중에 계속 실행되며, 다른 장애로 인해 종료되지 않는다고 가정합니다. 요약하면 노드와 Kubernetes 컨트롤 플레인 간의 네트워크 연결 해제 중에 정적 안정성을 달성할 수 있지만 연결이 복원될 때까지 노드 또는 워크로드에서 변경 작업을 수행할 수 없습니다. 네트워크 연결 해제의 특성에 따라 다양한 포드 장애 조치 동작을 생성하는 다섯 가지 주요 시나리오가 있습니다. 모든 시나리오에서 노드가 Kubernetes 컨트롤 플레인에 다시 연결되면 운영자 개입 없이 클러스터가 다시 정상 상태가 됩니다. 아래 시나리오에서는 관찰 결과에 따라 예상되는 결과를 간략하게 설명하지만 이러한 결과가 가능한 모든 애플리케이션 및 클러스터 구성에 적용되지는 않을 수 있습니다. ### 시나리오 1: 전체 클러스터 중단 **예상 결과**: 연결할 수 없는 노드의 포드는 제거되지 않으며 해당 노드에서 계속 실행됩니다. 전체 클러스터 중단은 클러스터의 모든 노드가 Kubernetes 컨트롤 플레인에서 연결 해제되었음을 의미합니다. 이 시나리오에서 컨트롤 플레인의 node-lifecycle-controller는 클러스터의 모든 노드에 연결할 수 없음을 감지하고 포드 제거를 취소합니다. 클러스터 관리자는 연결 해제 `Not Ready` 중에 상태의 모든 노드를 볼 수 있습니다. 포드 상태는 변경되지 않으며 연결 해제 및 후속 재연결 중에 노드에 새 포드가 예약되지 않습니다. ### 시나리오 2: 전체 영역 중단 **예상 결과**: 연결할 수 없는 노드의 포드는 제거되지 않으며 해당 노드에서 계속 실행됩니다. 전체 영역 중단은 영역의 모든 노드가 Kubernetes 컨트롤 플레인에서 연결 해제되었음을 의미합니다. 이 시나리오에서 컨트롤 플레인의 node-lifecycle-controller는 영역의 모든 노드에 연결할 수 없음을 감지하고 포드 제거를 취소합니다. 클러스터 관리자는 연결 해제 `Not Ready` 중에 상태의 모든 노드를 볼 수 있습니다. 포드 상태는 변경되지 않으며 연결 해제 및 후속 재연결 중에 노드에 새 포드가 예약되지 않습니다. ### 시나리오 3: 대부분 영역 중단 **예상 결과**: 연결할 수 없는 노드의 포드는 제거되지 않으며 해당 노드에서 계속 실행됩니다. 대다수 영역 중단은 지정된 영역의 대부분의 노드가 Kubernetes 컨트롤 플레인에서 연결 해제됨을 의미합니다. Kubernetes의 영역은 `topology.kubernetes.io/zone` 레이블이 동일한 노드로 정의됩니다. 클러스터에 영역이 정의되지 않은 경우 대부분의 중단은 전체 클러스터의 노드 대부분이 연결 해제됨을 의미합니다. 기본적으로 대다수는 Kubernetes와 EKS 모두에서 55%로 `unhealthy-zone-threshold`설정된 node-lifecycle-controller의에 의해 정의됩니다. `large-cluster-size-threshold`는 EKS에서 100,000으로 설정되므로 영역 내 노드의 55% 이상에 연결할 수 없는 경우 포드 제거가 취소됩니다(대부분의 클러스터가 100,000개 노드보다 훨씬 작은 경우). 클러스터 관리자는 연결 해제 `Not Ready` 중에 상태의 대부분의 노드를 영역에서 볼 수 있지만 포드의 상태는 변경되지 않으며 다른 노드에서 다시 예약되지 않습니다. 위의 동작은 노드 3개보다 큰 클러스터에만 적용됩니다. 노드가 3개 이하인 클러스터에서는 연결할 수 없는 노드의 포드가 제거되도록 예약되고 정상 노드에 새 포드가 예약됩니다. 테스트 중에 대부분의 영역 노드에 연결할 수 없는 경우에도 네트워크 연결 해제 중에 정확히 하나의 연결할 수 없는 노드에서 포드가 제거되는 경우가 가끔 있었습니다. Kubernetes node-lifecycle-controller에서 이러한 동작의 원인으로 발생할 수 있는 경합 상태를 계속 조사하고 있습니다. ### 시나리오 4: 소수 영역 중단 **예상 결과**: 연결할 수 없는 노드에서 포드가 제거되고 사용 가능한 적격 노드에 새 포드가 예약됩니다. 소수의 중단은 영역의 노드 중 더 적은 비율이 Kubernetes 컨트롤 플레인에서 연결 해제됨을 의미합니다. 클러스터에 영역이 정의되지 않은 경우 소수의 중단은 전체 클러스터에 있는 소수의 노드가 연결 해제됨을 의미합니다. 명시된 대로 소수는 기본적으로 55%인 node-lifecycle-controller의 `unhealthy-zone-threshold` 설정에 의해 정의됩니다. 이 시나리오에서 네트워크 연결 해제가 `default-unreachable-toleration-seconds` (5분) 및 `node-monitor-grace-period` (40초)보다 오래 지속되고 영역 내 노드의 55% 미만이 연결할 수 없는 경우 새 포드는 정상 노드에 예약되고 연결할 수 없는 노드의 포드는 제거 대상으로 표시됩니다. 클러스터 관리자는 정상 노드에서 생성된 새 포드를 보고 연결 해제된 노드의 포드는 로 표시됩니다`Terminating`. 연결이 해제된 노드의 포드는 `Terminating` 상태가 되더라도 노드가 Kubernetes 컨트롤 플레인에 다시 연결될 때까지 완전히 제거되지 않습니다. ## 시나리오 5: 네트워크 중단 중 노드 재시작 **예상 결과**: 연결할 수 없는 노드의 포드는 노드가 Kubernetes 컨트롤 플레인에 다시 연결될 때까지 시작되지 않습니다. 포드 장애 조치는 연결할 수 없는 노드 수에 따라 시나리오 1\$13에 설명된 로직을 따릅니다. 네트워크 중단 중 노드 재시작은 네트워크 연결 해제와 동시에 노드에서 다른 장애(예: 전원 주기, out-of-memory 이벤트 또는 기타 문제)가 발생했음을 의미합니다. 네트워크 연결 해제가 시작될 때 해당 노드에서 실행 중이었던 포드는 kubelet도 다시 시작되었다면 연결 해제 중에 자동으로 다시 시작되지 않습니다. kubelet은 시작 중에 Kubernetes API 서버를 쿼리하여 실행해야 하는 포드를 알아봅니다. 네트워크 연결 해제로 인해 kubelet이 API 서버에 연결할 수 없는 경우 포드를 시작하는 데 필요한 정보를 검색할 수 없습니다. 이 시나리오에서는 `crictl` CLI와 같은 로컬 문제 해결 도구를 사용하여 포드를 'break-glass' 측정값으로 수동으로 시작할 수 없습니다. Kubernetes는 일반적으로 기존 포드를 다시 시작하는 대신 장애가 발생한 포드를 제거하고 새 포드를 생성합니다(자세한 내용은 컨테이너식 GitHub 리포지토리의 [\$110213](https://github.com/containerd/containerd/pull/10213) 참조). 정적 포드는 kubelet에 의해 제어되고 이러한 시나리오 중에 다시 시작할 수 있는 유일한 Kubernetes 워크로드 객체입니다. 그러나 일반적으로 애플리케이션 배포에 정적 포드를 사용하지 않는 것이 좋습니다. 대신 여러 호스트에 여러 복제본을 배포하여 노드 장애 및 노드와 Kubernetes 컨트롤 플레인 간의 네트워크 연결 해제와 같은 여러 동시 장애 발생 시 애플리케이션 가용성을 보장합니다. # 네트워크 연결 해제를 통한 애플리케이션 네트워크 트래픽 이 페이지의 주제는 노드와 Kubernetes 컨트롤 플레인 간의 네트워크 연결 해제 중 Kubernetes 클러스터 네트워킹 및 애플리케이션 트래픽과 관련이 있습니다. ## Cilium Cilium에는 IP 주소 관리(IPAM), 캡슐화, 로드 밸런싱 및 클러스터 라우팅을 위한 여러 모드가 있습니다. 이 가이드에서 검증된 모드는 클러스터 범위 IPAM, VXLAN 오버레이, BGP 로드 밸런싱 및 kube-proxy를 사용했습니다. 또한 Cilium은 BGP 로드 밸런싱 없이 사용되어 MetalLB L2 로드 밸런싱으로 대체되었습니다. Cilium 설치의 기본은 Cilium 연산자와 Cilium 에이전트로 구성됩니다. Cilium 연산자는 배포로 실행되고 Cilium 사용자 지정 리소스 정의(CRDs를 등록하고, IPAM을 관리하고, 클러스터 객체를 [다른 기능](https://docs.cilium.io/en/stable/internals/cilium_operator/) 중에서 Kubernetes API 서버와 동기화합니다. Cilium 에이전트는 각 노드에서 DaemonSet로 실행되고 eBPF 프로그램을 관리하여 클러스터에서 실행되는 워크로드에 대한 네트워크 규칙을 제어합니다. 일반적으로 Cilium에서 구성한 클러스터 내 라우팅은 네트워크 연결 해제 중에도 계속 사용할 수 있으며 포드 네트워크에 대한 클러스터 내 트래픽 흐름 및 IP 테이블(iptables) 규칙을 준수하여 확인할 수 있습니다. ``` ip route show table all | grep cilium ``` ``` 10.86.2.0/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450 10.86.2.64/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450 10.86.2.128/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450 10.86.2.192/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450 10.86.3.0/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 10.86.3.16 dev cilium_host proto kernel scope link ... ``` 그러나 네트워크 연결이 끊어지는 동안 상태 확인이 Kubernetes API 서버와의 연결 상태와 결합되어 Cilium 운영자와 Cilium 에이전트가 다시 시작됩니다. 네트워크 연결 해제 중에 Cilium 운영자 및 Cilium 에이전트의 로그에 다음이 표시될 것으로 예상됩니다. 네트워크 연결 해제 중에 `crictl` CLI와 같은 도구를 사용하여 로그를 포함하여 이러한 구성 요소의 재시작을 관찰할 수 있습니다. ``` msg="Started gops server" address="127.0.0.1:9890" subsys=gops msg="Establishing connection to apiserver" host="https://:443" subsys=k8s-client msg="Establishing connection to apiserver" host="https://:443" subsys=k8s-client msg="Unable to contact k8s api-server" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" ipAddr="https://:443" subsys=k8s-client msg="Start hook failed" function="client.(*compositeClientset).onStart (agent.infra.k8s-client)" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" msg="Start failed" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" duration=1m5.003834026s msg=Stopping msg="Stopped gops server" address="127.0.0.1:9890" subsys=gops msg="failed to start: Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" subsys=daemon ``` 애플리케이션 로드 밸런싱에 Cilium의 BGP 컨트롤 플레인 기능을 사용하는 경우 BGP 스피커 기능이 Cilium 에이전트와 통합되고 Kubernetes 컨트롤 플레인에서 연결이 해제되면 Cilium 에이전트가 계속 다시 시작되므로 네트워크 연결 해제 중에 포드 및 서비스에 대한 BGP 세션이 중단될 수 있습니다. 자세한 내용은 Cilium 설명서의 Cilium BGP 컨트롤 플레인 작업 가이드를 참조하세요. 또한 전원 주기 또는 시스템 재부팅과 같은 네트워크 연결 해제 중에 동시 장애가 발생하는 경우 노드가 Kubernetes 컨트롤 플레인에 다시 연결되고 Cilium이 다시 시작될 때 경로가 다시 생성되더라도 이러한 작업을 통해 Cilium 경로가 보존되지 않습니다. ## Calico *곧 출시 예정* ## MetalLB MetalLB에는 [L2 모드](https://metallb.universe.tf/concepts/layer2/)와 [BGP 모드라는 두 가지 로드 밸런싱 모드가 있습니다](https://metallb.universe.tf/concepts/bgp/). 이러한 로드 밸런싱 모드의 작동 방식과 제한 사항에 대한 자세한 내용은 MetalLB 설명서를 참조하세요. 이 가이드의 검증은 L2 모드에서 MetalLB를 사용했습니다.이 모드에서는 클러스터의 한 시스템이 Kubernetes Service의 소유권을 가지며 IPv4용 ARP를 사용하여 로컬 네트워크에서 로드 밸런서 IP 주소에 연결할 수 있습니다. MetalLB를 실행할 때 IP 할당을 담당하는 컨트롤러와 IP 주소가 할당된 광고 서비스를 담당하는 각 노드에서 실행되는 스피커가 있습니다. MetalLB 컨트롤러는 배포로 실행되고 MetalLB 스피커는 DaemonSet로 실행됩니다. 네트워크 연결이 끊어지는 동안 MetalLB 컨트롤러와 스피커는 Kubernetes API 서버에서 클러스터 리소스를 관찰하지 못하지만 계속 실행됩니다. 무엇보다도 외부 연결에 MetalLB를 사용하는 서비스는 네트워크 연결 해제 중에도 계속 사용할 수 있고 액세스할 수 있습니다. ## kube-proxy EKS 클러스터에서 kube-proxy는 각 노드에서 DaemonSet로 실행되며 서비스 IP 주소를 기본 포드의 IP 주소로 변환하여 서비스와 포드 간의 통신을 활성화하는 네트워크 규칙을 관리하는 역할을 합니다. kube-proxy로 구성된 IP 테이블(iptables) 규칙은 네트워크 연결 해제 중에 유지되며 클러스터 내 라우팅은 계속 작동하고 kube-proxy 포드는 계속 실행됩니다. 다음 iptables 명령을 사용하여 kube-proxy 규칙을 관찰할 수 있습니다. 첫 번째 명령은 `PREROUTING` 체인을 통과하는 패킷이 `KUBE-SERVICES` 체인으로 전달되는 것을 보여줍니다. ``` iptables -t nat -L PREROUTING ``` ``` Chain PREROUTING (policy ACCEPT) target prot opt source destination KUBE-SERVICES all -- anywhere anywhere /* kubernetes service portals */ ``` `KUBE-SERVICES` 체인을 검사하면 다양한 클러스터 서비스에 대한 규칙을 볼 수 있습니다. ``` Chain KUBE-SERVICES (2 references) target prot opt source destination KUBE-SVL-NZTS37XDTDNXGCKJ tcp -- anywhere 172.16.189.136 /* kube-system/hubble-peer:peer-service cluster IP / KUBE-SVC-2BINP2AXJOTI3HJ5 tcp -- anywhere 172.16.62.72 / default/metallb-webhook-service cluster IP / KUBE-SVC-LRNEBRA3Z5YGJ4QC tcp -- anywhere 172.16.145.111 / default/redis-leader cluster IP / KUBE-SVC-I7SKRZYQ7PWYV5X7 tcp -- anywhere 172.16.142.147 / kube-system/eks-extension-metrics-api:metrics-api cluster IP / KUBE-SVC-JD5MR3NA4I4DYORP tcp -- anywhere 172.16.0.10 / kube-system/kube-dns:metrics cluster IP / KUBE-SVC-TCOU7JCQXEZGVUNU udp -- anywhere 172.16.0.10 / kube-system/kube-dns:dns cluster IP / KUBE-SVC-ERIFXISQEP7F7OF4 tcp -- anywhere 172.16.0.10 / kube-system/kube-dns:dns-tcp cluster IP / KUBE-SVC-ENODL3HWJ5BZY56Q tcp -- anywhere 172.16.7.26 / default/frontend cluster IP / KUBE-EXT-ENODL3HWJ5BZY56Q tcp -- anywhere / default/frontend loadbalancer IP / KUBE-SVC-NPX46M4PTMTKRN6Y tcp -- anywhere 172.16.0.1 / default/kubernetes:https cluster IP / KUBE-SVC-YU5RV2YQWHLZ5XPR tcp -- anywhere 172.16.228.76 / default/redis-follower cluster IP / KUBE-NODEPORTS all -- anywhere anywhere / kubernetes service nodeports; NOTE: this must be the last rule in this chain */ ``` 프런트엔드 서비스의 체인에서 애플리케이션을 검사하면 서비스를 지원하는 포드 IP 주소를 확인할 수 있습니다. ``` iptables -t nat -L KUBE-SVC-ENODL3HWJ5BZY56Q ``` ``` Chain KUBE-SVC-ENODL3HWJ5BZY56Q (2 references) target prot opt source destination KUBE-SEP-EKXE7ASH7Y74BGBO all -- anywhere anywhere /* default/frontend -> 10.86.2.103:80 / statistic mode random probability 0.33333333349 KUBE-SEP-GCY3OUXWSVMSEAR6 all -- anywhere anywhere / default/frontend -> 10.86.2.179:80 / statistic mode random probability 0.50000000000 KUBE-SEP-6GJJR3EF5AUP2WBU all -- anywhere anywhere / default/frontend -> 10.86.3.47:80 */ ``` 다음 kube-proxy 로그 메시지는 네트워크 연결 해제 중에 Kubernetes API 서버에서 노드 및 엔드포인트 리소스에 대한 업데이트를 감시하려고 할 때 예상됩니다. ``` "Unhandled Error" err="k8s.io/client-go/informers/factory.go:160: Failed to watch *v1.Node: failed to list *v1.Node: Get \"https:///api/v1/nodes?fieldSelector=metadata.name%3D&resourceVersion=2241908\": dial tcp :443: i/o timeout" logger="UnhandledError" "Unhandled Error" err="k8s.io/client-go/informers/factory.go:160: Failed to watch *v1.EndpointSlice: failed to list *v1.EndpointSlice: Get \"https:///apis/discovery.k8s.io/v1/endpointslices?labelSelector=%21service.kubernetes.io%2Fheadless%2C%21service.kubernetes.io%2Fservice-proxy-name&resourceVersion=2242090\": dial tcp :443: i/o timeout" logger="UnhandledError" ``` ## CoreDNS 기본적으로 EKS 클러스터의 포드는 CoreDNS 클러스터 IP 주소를 클러스터 내 DNS 쿼리의 이름 서버로 사용합니다. EKS 클러스터에서 CoreDNS는 노드에서 배포로 실행됩니다. 하이브리드 노드를 사용하면 하이브리드 노드에서 로컬로 실행되는 CoreDNS 복제본이 있는 경우 네트워크 연결 해제 중에 포드가 CoreDNS와 계속 통신할 수 있습니다. 클라우드에 노드가 있고 온프레미스 환경에 하이브리드 노드가 있는 EKS 클러스터가 있는 경우 각 환경에 하나 이상의 CoreDNS 복제본을 사용하는 것이 좋습니다. CoreDNS는 네트워크 연결 해제 전에 생성된 레코드에 대한 DNS 쿼리를 계속 제공하고 정적 안정성을 위해 네트워크 재연결을 통해 계속 실행됩니다. 다음 CoreDNS 로그 메시지는 Kubernetes API 서버의 객체를 나열하려고 할 때 네트워크 연결 해제 중에 예상됩니다. ``` Failed to watch *v1.Namespace: failed to list *v1.Namespace: Get "https://:443/api/v1/namespaces?resourceVersion=2263964": dial tcp :443: i/o timeout Failed to watch *v1.Service: failed to list *v1.Service: Get "https://:443/api/v1/services?resourceVersion=2263966": dial tcp :443: i/o timeout Failed to watch *v1.EndpointSlice: failed to list *v1.EndpointSlice: Get "https://:443/apis/discovery.k8s.io/v1/endpointslices?resourceVersion=2263896": dial tcp : i/o timeout ``` # 네트워크 연결 해제를 통해 자격 증명 호스팅 EKS Hybrid Nodes는 EKS 컨트롤 플레인으로 노드를 인증하는 데 사용되는 임시 IAM 자격 증명을 위해 AWS Systems Manager(SSM) 하이브리드 활성화 및 AWS IAM Roles Anywhere와 통합됩니다. SSM과 IAM Roles Anywhere 모두 온프레미스 호스트에서 관리하는 임시 자격 증명을 자동으로 새로 고칩니다. 클러스터의 하이브리드 노드에서 SSM 하이브리드 활성화 또는 IAM Roles Anywhere와 같은 단일 자격 증명 공급자를 사용하는 것이 좋지만 둘 다 사용하는 것은 아닙니다. ## SSM 하이브리드 활성화 SSM에서 프로비저닝한 임시 자격 증명은 1시간 동안 유효합니다. SSM을 자격 증명 공급자로 사용할 때는 자격 증명 유효 기간을 변경할 수 없습니다. 임시 자격 증명은 만료되기 전에 SSM에 의해 자동으로 교체되며, 교체는 노드 또는 애플리케이션의 상태에 영향을 주지 않습니다. 그러나 SSM 에이전트와 SSM 리전 엔드포인트 간에 네트워크 연결이 끊어지면 SSM이 자격 증명을 새로 고칠 수 없으며 자격 증명이 만료될 수 있습니다. SSM은 SSM 리전 엔드포인트에 연결할 수 없는 경우 자격 증명 새로 고침 재시도에 지수 백오프를 사용합니다. SSM 에이전트 버전 `3.3.808.0` 이상(2024년 8월 릴리스)에서는 지수 백오프가 30분으로 제한됩니다. 네트워크 연결 해제 기간에 따라 SSM이 자격 증명을 새로 고치는 데 최대 30분이 걸릴 수 있으며, 자격 증명이 새로 고쳐질 때까지 하이브리드 노드가 EKS 컨트롤 플레인에 다시 연결되지 않습니다. 이 시나리오에서는 SSM 에이전트를 다시 시작하여 자격 증명을 강제로 새로 고칠 수 있습니다. 현재 SSM 자격 증명 새로 고침 동작의 부작용으로 각 노드의 SSM 에이전트가 자격 증명을 새로 고치는 시점에 따라 노드가 서로 다른 시간에 다시 연결될 수 있습니다. 따라서 이미 다시 연결된 노드에 아직 다시 연결되지 않은 노드에서 포드 장애 조치가 발생할 수 있습니다. SSM 에이전트 버전을 가져옵니다. SSM 콘솔의 Fleet Manager 섹션을 확인할 수도 있습니다. ``` # AL2023, RHEL yum info amazon-ssm-agent # Ubuntu snap list amazon-ssm-agent ``` SSM 에이전트를 다시 시작합니다. ``` # AL2023, RHEL systemctl restart amazon-ssm-agent # Ubuntu systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent ``` SSM 에이전트 로그 보기: ``` tail -f /var/log/amazon/ssm/amazon-ssm-agent.log ``` 네트워크 연결 해제 중 예상되는 로그 메시지: ``` INFO [CredentialRefresher] Credentials ready INFO [CredentialRefresher] Next credential rotation will be in 29.995040663666668 minutes ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed INFO [CredentialRefresher] Sleeping for 35s before retrying retrieve credentials ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed INFO [CredentialRefresher] Sleeping for 56s before retrying retrieve credentials ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed INFO [CredentialRefresher] Sleeping for 1m24s before retrying retrieve credentials ``` ## IAM Roles Anywhere IAM Roles Anywhere에서 프로비저닝한 임시 자격 증명은 기본적으로 1시간 동안 유효합니다. IAM Roles Anywhere 프로파일의 [https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session.html#credentials-object](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session.html#credentials-object) 필드를 통해 IAM Roles Anywhere로 자격 증명 유효 기간을 구성할 수 있습니다. 최대 자격 증명 유효 기간은 12시간입니다. 하이브리드 노드 IAM 역할의 [https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-maxsessionduration.html](https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-maxsessionduration.html) 설정은 IAM Roles Anywhere 프로필의 `durationSeconds` 설정보다 커야 합니다. IAM Roles Anywhere를 하이브리드 노드의 자격 증명 공급자로 사용하는 경우 kubelet이 온디맨드 자격 증명을 얻기 `aws_signing_helper credential-process` 위해를 호출하기 때문에 네트워크 연결 해제 후 일반적으로 네트워크 복원 후 몇 초 내에 EKS 컨트롤 플레인에 다시 연결합니다. 하이브리드 노드 또는 네트워크 연결 해제와 직접 관련이 없지만 IAM Roles Anywhere를 사용할 때 인증서 만료에 대한 알림 및 알림을 구성할 수 있습니다. 자세한 내용은 [IAM Roles Anywhere의 알림 설정 사용자 지정](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/customize-notification-settings.html)을 참조하세요.