지난 1개월 동안 GKE 클러스터에서 4개의 AUTO_REPAIR_NODES이벤트(명령어로 표시됨 )가 발생했습니다 . gcloud container operations list노드 자동 복구의 결과는 노드가 다시 생성되어 새 외부 IP가 연결되고, 타사 서비스에 의해 허용되지 않은 새 외부 IP로 인해 결국 새 노드에서 실행되는 서비스가 실패하게 되는 것입니다.
나는 우리가 "자동 노드 복구"를 Kubernetes 클러스터에서 활성화했고 이를 비활성화하고 싶은 유혹을 느꼈지만 그렇게 하기 전에 상황에 대해 더 자세히 알아야 합니다.
내 질문은 다음과 같습니다
- 애초에 노드를 비정상으로 만드는 일반적인 원인은 무엇입니까? 나는 이 기사를 알고 있다https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-repair#node_repair_process"노드가 다음을 보고합니다.준비 안 됨주어진 시간 임계값에 대한 연속 확인 상태"는 자동 복구를 트리거합니다. 그러나 노드가준비 안 됨?
- 나도 이 글을 알고 있다https://kubernetes.io/docs/concepts/architecture/nodes/#node-status이는 노드 상태의 전체 목록을 언급합니다: {OutOfDisk, Ready, MemoryPressure, PIDPressure, DiskPressure, NetworkUnavailable, ConfigOK}. 노드에 대해 {OutOfDisk, MemoryPressure, PIDPressure, DiskPressure, NetworkUnavailable} 중 하나라도 true가 되면 해당 노드가 NotReady가 되는지 궁금합니다.
- 클러스터에서 "자동 노드 복구"를 비활성화하면 어떤 부정적인 결과가 발생할 수 있습니까?기본적으로 자동 복구된 노드와 화이트리스트에 추가되지 않은 새로 연결된 IP보다 더 나쁜 상황에 처할 수 있는지 궁금합니다.. "자동 노드 복구"가 비활성화되면 자동 복구된 비정상 노드에서 실행 중인 포드의 경우 Kubernetes가 다른 노드에 새 포드를 생성합니까?
답변1
마스터는 기본적으로 노드에 대한 상태 확인을 수행합니다. 노드가 응답할 수 없거나 노드가 NotReady라고 선언하면 노드 자동 복구를 통해 복구됩니다. GKE 노드에는 OS 문제를 감지할 수 있는 노드 문제 감지기도 있습니다.
언급된 조건으로 인해 노드가 NotReady 상태가 될 수 있습니다. OS 수준에서 오류가 반복되는 등 다른 가능한 요인도 있습니다.
노드 자동 복구를 끄면 노드가 NotReady 상태로 유지될 수 있습니다. 많은 경우에 노드는 포드나 프로세스를 종료하여 문제를 해결하려고 시도하지만 노드가 NotReady에서 멈출 수도 있습니다.
노드 자동 복구를 비활성화하는 대신 화이트리스트 요구 사항에 따라 설정을 변경하는 것이 좋습니다. 대신에 다음을 수행할 수 있습니다.모든 아웃바운드 GKE 트래픽에 대해 NAT 게이트웨이 설정; NAT에 고정 IP를 할당하고 해당 IP를 화이트리스트에 추가하는 것에 대해 걱정할 수 있습니다. 더 이상 노드가 IP를 변경하는 것에 대해 걱정할 필요가 없습니다.