Kubernetes: Up and Running, 제3판

7장. 서비스 검색

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

Kubernetes는 매우 역동적인 시스템입니다. 시스템은 노드에 파드를 배치하고, 실행 중인지 확인하고, 필요에 따라 스케줄을 재조정하는 데 관여한다. 로드에 따라 파드 수를 자동으로 변경하는 방법( "레플리카셋 자동 스케일링" 참조)이 있다("수평 파드 자동 스케일링" 등). 시스템의 API 중심적 특성은 다른 사람들이 더 높은 수준의 자동화를 만들도록 장려한다.

Kubernetes의 동적 특성으로 인해 많은 것을 쉽게 실행할 수 있지만, 이러한 것들을 찾는 데 있어서는 문제가 발생합니다. 대부분의 기존 네트워크 인프라는 Kubernetes가 제공하는 수준의 역동성을 위해 구축되지 않았습니다.

서비스 검색이란 무엇인가요?

이러한 종류의 문제와 솔루션의 일반적인 명칭은 서비스 검색입니다. 서비스 검색 도구는 어떤 프로세스가 어떤 서비스에 대해 어떤 주소에서 수신 대기 중인지 찾는 문제를 해결하는 데 도움이 됩니다. 좋은 서비스 검색 시스템은 사용자가 이 정보를 빠르고 안정적으로 해결할 수 있게 해줍니다. 또한 좋은 시스템은 지연 시간이 짧아 서비스와 관련된 정보가 변경되는 즉시 클라이언트가 업데이트됩니다. 마지막으로, 좋은 서비스 검색 시스템은 해당 서비스가 무엇인지에 대한 보다 풍부한 정의를 저장할 수 있습니다. 예를 들어 서비스와 관련된 포트가 여러 개 있을 수 있습니다.

DNS(도메인 이름 시스템)는 인터넷에서 서비스를 검색하는 전통적인 시스템입니다. DNS는 광범위하고 효율적인 캐싱을 통해 비교적 안정적인 이름 확인을 위해 설계되었습니다. 인터넷에는 훌륭한 시스템이지만 역동적인 Kubernetes의 세계에서는 부족합니다.

안타깝게도 많은 시스템(예: 기본적으로 Java)은 DNS에서 이름을 직접 조회하고 이를 다시 확인하지 않습니다. 이로 인해 클라이언트가 오래된 매핑을 캐싱하고 잘못된 IP와 통신하게 될 수 있습니다. TTL(타임투라이브)이 짧고 클라이언트가 잘 작동하더라도 이름 확인이 변경되는 시점과 클라이언트가 이를 인지하는 시점 사이에는 자연스러운 지연이 발생합니다. 일반적인 DNS 쿼리에서 반환할 수 있는 정보의 양과 유형에도 자연스러운 제한이 있습니다. 단일 이름에 대해 20~30개의 주소(A) 레코드가 지나면 문제가 발생하기 시작합니다. 서비스(SRV) 레코드는 일부 문제를 해결하지만 사용하기가 매우 어렵습니다. 마지막으로 클라이언트가 DNS 레코드에서 여러 IP를 처리하는 방법은 일반적으로 첫 번째 IP 주소를 가져와 DNS 서버가 레코드 순서를 무작위화하거나 라운드 로빈으로 처리하는 것입니다. 이는 보다 목적에 맞게 설계된 로드 밸런싱을 대체할 수 없습니다.

서비스 개체

Kubernetes의 실제 서비스 검색은 서비스 오브젝트에서 시작됩니다. Service 오브젝트는 네임드 레이블 선택기를 생성하는 방법입니다. 앞으로 살펴보겠지만, Service 객체는 ...