Kubernetes 정리 199: Prerequisite - DNS

1. Name Resolution

동일한 네트워크에 속하는 두 대의 컴퓨터 A와 B가 있으며 IP 주소 192.168.1.10 및 1.11이 할당되었습니다. 다른 컴퓨터의 IP 주소를 사용하여 다른 컴퓨터에서 한 컴퓨터를 ping할 수 있습니다. 시스템 B에 데이터베이스 서비스가 있다는 것을 알고 있으므로, 시스템 B의 IP 주소를 기억하는 대신 이름을 db로 지정하기로 결정합니다. 앞으로는 IP 주소 대신 이름 db를 사용하여 시스템 B를 ping하려고 합니다. 지금 db에 ping을 시도하면 호스트 A가 db라는 호스트를 인식하지 못하는 것을 볼 수 있습니다. 어떻게 고칠 수 있을까요? 기본적으로 시스템 A에게 IP 주소 192.168.1.11의 시스템 B에 DB라는 이름이 있다고 알려야 합니다. 시스템 A에게 "db"라고 말할 때 IP 192.168.1.11을 의미한다고 말하고 싶을 것입니다. 시스템 A의 etc/hosts 파일에 항목을 추가하여 이를 수행할 수 있습니다. 호스트가 시스템 B를 볼 IP 주소와 이름을 언급하십시오. 우리는 시스템 A에게 192.168.1.11의 IP가 DB라는 호스트라고 말했습니다. 이제 db에 대한 ping이 올바른 IP로 전송되고 성공합니다.

여기서 주목해야 할 중요한 점이 있습니다. 우리는 시스템 A에게 192.168.1.11의 IP가 db라는 호스트라고 말했습니다. 우리가 etc/hosts 파일에 넣은 것이 진실인지 아닌지는 상관 없이 호스트 A는 이를 당연하게 여깁니다. 그러나 그것이 진실이 아닐 수도 있습니다. 호스트 A는 시스템 B의 실제 이름이 db인지 확인하지 않습니다. 예를 들어, 시스템 B에서 hostname 커맨드를 실행하면 이름이 host-2라는 것을 알 수 있습니다. 그러나 호스트 A는 신경 쓰지 않습니다. 호스트 파일에 있는 내용으로 이동합니다.

시스템 B가 Google이라고 믿도록 시스템 A를 속일 수도 있습니다. www.google.com 에 대한 IP 매핑을 사용하여 호스트 파일에 항목을 추가하기만 하면 됩니다. 그런 다음 Google에 핑하면 시스템 B에서 응답을 받게 됩니다. 따라서 동일한 시스템을 가리키는 두 개의 이름이 있습니다. 하나는 db이고 다른 하나는 Google입니다. 그리고 두 이름 중 하나를 사용하여 시스템 B를 읽을 수 있습니다. etc/hosts 파일에서 원하는 만큼의 서버에 대해 원하는 만큼의 이름을 가질 수 있습니다. 호스트 A에서 이름으로 다른 호스트를 참조할 때마다 ping 커맨드나 SSH 커맨드를 통해 또는 이 시스템 내의 애플리케이션이나 tool을 통해 호스트는 해당 호스트의 IP 주소를 찾기 위해 etc/hosts 파일을 찾습니다. 이러한 방식으로 호스트 이름을 IP 주소로 변환하는 것을 name resolution이라고 합니다.

2. DNS

소수의 시스템으로 구성된 소규모 네트워크 내에서 etc/hosts 파일의 항목을 쉽게 사용할 수 있습니다. 각 시스템에서 모두 다른 시스템을 지정합니다. 과거에는 그렇게 했습니다. 환경이 커지면 이러한 파일과 항목을 관리하는 것이 너무 어려워집니다. 서버 중 하나의 IP가 변경되면 모든 호스트에서 항목을 수정해야 합니다. 따라서 이 모든 항목을 중앙에서 관리할 단일 서버를 두기로 결정했습니다. 우리는 그것을 DNS 서버라고 부릅니다.

자체 etc/hosts 파일 대신 호스트 이름을 IP 주소로 확인해야 하는 경우에 모든 호스트가 해당 서버를 조회하도록 지정합니다.

 

호스트를 DNS 서버로 지정하려면 어떻게 해야 할까요? DNS 서버의 IP는 192.168.1.100입니다. 모든 호스트에는 etc/resolv.conf에 DNS resolution configuration 파일이 있습니다. DNS 서버의 주소를 지정하여 항목을 추가합니다. "nameserver"라고 말하고 192.168.1.100을 가리키면 됩니다. 이것이 모든 호스트에 configuration되면 호스트가 알지 못하는 호스트 이름을 발견할 때마다 DNS 서버에서 조회합니다. 호스트의 IP가 변경되는 경우 DNS 서버를 업데이트하기만 하면 모든 호스트가 앞으로 새로운 IP 주소를 확인할 수 있습니다. 더 이상 모든 호스트의 etc/hosts 파일 항목이 필요하지 않습니다. 그러나 이것이 호스트 파일에 항목을 가질 수 없다는 의미는 아닙니다. 당신은 여전히 호스트파일 항목을 가질 수 있습니다. 예를 들어 필요에 따라 테스트 서버를 프로비저닝한다고 가정해 보겠습니다. 다른 사람들이 이름으로 서버를 확인할 필요가 없다고 생각하므로, DNS 서버에 추가할 필요가 없습니다. 이 경우 호스트의 etc/hosts 파일에 항목을 추가하여 이 서버를 확인할 수 있습니다. 이제 서버를 확인할 수 있지만 다른 시스템에서는 그렇게 할 수 없습니다. 따라서 시스템은 etc/hosts 파일과 원격 DNS 서버에서 호스트 이름 대 IP 매핑을 사용할 수 있습니다. etc/hosts 파일과 DNS에 각각 하나씩 항목이 있으면 어떻게 될까요? 내 로컬 파일에 항목이 192.168.1.115로 설정되어 있고 누군가 동일한 호스트에 대한 항목을 DNS 서버의 192.1.68.116에 추가했습니다. 이 경우 호스트는 먼저 로컬 etc/hosts 파일에서 그런 다음 이름 서버를 확인합니다. 따라서 로컬 etc/hosts 파일에서 항목을 찾으면 해당 항목을 사용합니다. 그렇지 않은 경우 DNS 서버에서 해당 호스트를 찾습니다. 하지만 그 순서는 바뀔 수 있습니다. 순서는 etc/nsswitch.conf 파일의 항목으로 정의됩니다.

보시다시피 호스트 항목이 있는 줄은 보면 순서대로 첫 번째 files이고 그 다음이 dns입니다. 파일은 etc/hosts 파일을 의미하고 DNS는 DNS 서버를 의미합니다. 따라서 모든 호스트 이름에 대해 호스트는 먼저 etc/hosts 파일을 살펴보고 찾을 수 없으면 DNS 서버를 찾는다는 의미입니다. 이 순서는 파일에서 이 항목을 편집하여 수정할 수 있습니다. 이 순서에 따라 호스트는 테스트 서버를 192.168.1.15로 확인합니다.

목록에 없는 서버에 ping을 시도하면 어떻게 됩니까? 예를 들어 www.facebook.com에 ping을 시도합니다. etc/hosts 파일에 facebook.com이 없고 DNS 서버에도 없습니다. 따라서 그 경우에는 실패합니다.

resolv.conf 파일에 다른 항목을 추가하여 Facebook을 알고 있는 이름 서버를 가리킬 수 있습니다. 예를 들어 8.8.8.8은 Google에서 호스팅하는 인터넷에서 사용할 수 있는 널리 알려진 공용 이름 서버로 인터넷의 모든 웹사이트에 대해 알고 있습니다. 이와 같이 여러 개의 이름 서버를 호스트에 configuration할 수 있지만 네트워크의 모든 호스트에 configuration해야 합니다. 모든 호스트에 configuration된 네트워크 내에 nameserver가 이미 있습니다. 따라서 이 경우 알 수 없는 호스트 이름을 인터넷의 공용 이름 서버로 전달하도록 DNS 서버 자체를 구성할 수 있습니다. facebook.com과 같은 외부 사이트를 ping할 수 없어야 합니다.

 

3. Domain Names

지금까지 우리는 Web, DB, NFS 등과 같은 이름으로 시스템을 읽으려고 했습니다. 하지만 방금 www.facebook.com 에서 Facebook에 ping을 시도했습니다. 끝에 www와 .com이 있는 이 이름은 무엇입니까? 도메인 네임이라고 하며 호스트에 대해 했던 것처럼 공용 인터넷에서 기억할 수 있는 이름으로 IPS가 변환하는 방식입니다. 이제 점으로 구분된 이 형식을 사용하는 이유는 유사한 항목을 함께 그룹화하기 위한 것입니다. 도메인 이름의 마지막 부분인 .coms, .nets, .edu, .org 등은 웹사이트의 의도를 나타내는 최상위 도메인입니다. 상업용 또는 일반용 .com, 네트워크용 .net, 교육 기관용 .edu, 비영리 기관용 .org.

한 가지를 예로 살펴보겠습니다. Google의 경우 점은 루트입니다. 그것이 모든 것이 시작되는 곳입니다. .com은 최상위 도메인입니다. Google은 Google에 할당된 도메인 이름이고 www는 하위 도메인입니다. 하위 도메인은 Google에서 항목을 추가로 그룹화하는 데 도움이 됩니다. 예를 들어 Google의 지도 서비스는 maps.google.com에서 사용할 수 있습니다. 따라서 map은 하위 도메인입니다. Google의 스토리지 서비스는 drive.google.com에서 사용할 수 있습니다. 모바일 앱은 apps.google.com에서 사용할 수 있습니다. Google의 이메일 서비스는 mail.google.com에서 사용할 수 있습니다. 필요에 따라 이들 각각을 많은 하위 도메인으로 추가로 나눌 수 있습니다. 따라서 트리 구조가 형성되는 것을 볼 수 있습니다.