kubernetes CKA study (26) - Prerequisite - Switching , Prerequisite - DNS, Prerequisite - CoreDNS
kubernetes CKA study
Prerequisite - Switching Routing
Switching
네트워크란 무엇인가요? 우리는 두 대의 컴퓨터 A와 B, 랩톱, 데스크톱, 클라우드의 VM을 가지고 있습니다. 시스템 A는 어떻게 B에 도달합니까? 우리는 그것들을 스위치에 연결하고 스위치는 두 시스템을 포함하는 네트워크를 생성합니다. 스위치에 연결하려면 호스트에 따라 물리적 또는 가상의 각 호스트에 인터페이스가 필요합니다. 호스트의 인터페이스를 보려면 ip link 커맨드를 사용합니다.
이 경우 스위치에 연결하는 데 사용할 eth0이라는 인터페이스가 있습니다. 이를 더 살펴보겠습니다. 주소가 192.168.1.0인 네트워크라고 가정해 보겠습니다. 동일한 네트워크에 있는 IP 주소로 시스템을 할당합니다. 이를 위해 ip addr 커맨드를 사용합니다.
링크가 작동되고 IP 주소가 할당되면 컴퓨터는 이제 스위치를 통해 서로 통신할 수 있습니다. 스위치는 네트워크 내에서만 통신할 수 있습니다. 즉, 네트워크의 호스트에서 패킷을 수신하여 동일한 네트워크 내의 다른 시스템으로 전달할 수 있습니다.
Routing
주소 192.168.2.0에 시스템 C와 D를 포함하는 또 다른 네트워크가 있다고 가정합니다. 시스템의 IP 주소는 192.168.2.10, 192.168.2.11입니다. 한 네트워크의 시스템이 다른 네트워크의 시스템에 어떻게 도달할 수 있을까요? IP 192.168.1.11를 사용하는 시스템 B는 어떻게 IP 2.10인 시스템 C에 도달할 수 있을까요? 여기서 라우터가 필요해집니다. 라우터는 두 네트워크를 함께 연결하는 데 도움이 되는 지능형 장치입니다. 따라서 네트워크 포트가 많은 또 다른 서버로 생각하면 됩니다. 두 개의 개별 네트워크에 연결되므로 각 네트워크에 하나씩 두 개의 IP가 할당됩니다. 첫 번째 네트워크에서 IP 주소 192.168. 1. 1를 할당합니다. 그리고 두 번째 네트워크에는 IP 2.1을 할당합니다. 이제 두 네트워크 간의 통신을 가능하게 하는 라우터가 두 네트워크에 연결되었습니다.
Gateway
시스템 B가 시스템 C로 패킷을 보내려고 할 때 라우터가 네트워크에서 패킷을 보낼 위치를 어떻게 알 수 있을까요? 라우터는 네트워크의 장치일 뿐입니다. 이를 위해서는 게이트웨이 또는 route로 시스템을 구성합니다. 네트워크가 방이라면 게이트웨이는 다른 네트워크나 인터넷으로 가는 외부 세계로 통하는 문입니다. 시스템은 문을 통해 어디로 가야 하는지 알아야 합니다.
시스템의 기존 라우팅 configuration을 보려면 route 커맨드를 실행하십시오. 커널의 라우팅 테이블을 표시합니다. 그리고 그 안에는 보시다시피 현재로서는 라우팅 configuration이 없습니다. 따라서 이 상태에서 시스템 B는 시스템 C에 도달할 수 없습니다. 192.168. 1. 0 범위 내에서 동일한 네트워크 내의 다른 시스템에만 도달할 수 있습니다.
네트워크 2.0의 시스템에 도달하도록 시스템 B의 게이트웨이를 구성하려면 ip route add 커맨드를 실행하고 192.168.1.1의 문 또는 게이트웨이를 통해 192.168. 2.0에 도달할 수 있도록 지정합니다.
route 커맨드를 다시 실행하면 192.168.2.0에 도달하기 위한 route가 추가되었음을 알 수 있습니다. 이제 이것은 모든 시스템에서 구성되어야 한다는 점을 기억하세요.
예를 들어, 시스템 C가 시스템 B로 패킷을 보내려면 시스템 C의 라우팅 테이블에 route를 추가하여 IP 주소 2.1로 구성된 라우터를 통해 1.0 네트워크에 액세스해야 합니다.
이제 이러한 시스템이 인터넷에 액세스해야 한다고 가정합니다. 172.217.194.0인터넷상의 네트워크에서 Google에 액세스해야 한다고 합시다. 따라서 라우터를 인터넷에 연결한 다음, 라우팅 테이블에 새 route를 추가하여 모든 트래픽을 네트워크 172.217.194으로 라우팅합니다.
인터넷에는 다양한 네트워크에 다양한 사이트가 있습니다. 동일한 라우터 IP 주소를 라우팅 테이블에 추가하는 대신, 경로를 모르는 네트워크에 대해 이 라우터를 default 게이트웨이로 사용한다고 간단히 말할 수 있습니다. 이렇게 하면 기존 네트워크 외부의 네트워크에 대한 모든 요청이 이 특정 라우터로 이동합니다.
따라서 이와 같은 간단한 설정에서는 default 게이트웨이가 라우터의 IP 주소로 설정된 단일 라우팅 테이블 항목만 있으면 됩니다. default라는 단어 대신 0.0.0.0이라고 표현해도 됩니다. 이는 모든 IP 대상을 의미합니다. 0.0.0.0 게이트웨이 필드 항목은 게이트웨이가 필요하지 않음을 나타냅니다. 예를 들어, 이 경우 시스템 C는 192. 168. 2. 0 네트워크에서는 자체 네트워크에 있기 때문에 게이트웨이가 필요하지 않습니다. 그러나 네트워크에 여러 개의 라우터가 있다고 가정해봅시다. 하나는 인터넷용이고 다른 하나는 내부 개인 네트워크용입니다.
그러면 각 네트워크에 대해 두 개의 별도 항목이 있어야 합니다. 내부 개인 네트워크에 대한 항목 하나와, 공용 네트워크를 포함한 다른 모든 네트워크에 대한 default 게이트웨이가 있는 다른 항목입니다. 따라서 시스템에서 인터넷에 연결하는 데 문제가 있는 경우 이 라우팅 테이블과 default 게이트웨이 configuration을 시작으로 살펴보는 것이 좋습니다.
이제 Linux 호스트를 라우터로 설정하는 방법을 살펴보겠습니다. 간단한 설정부터 시작하겠습니다. A, B, C 세 개의 호스트가 있습니다. A와 B는 네트워크(192.168.1.0)에 연결되어 있습니다. B와 C는 192.168.2.0로 연결되어 있습니다. 따라서 호스트 B는 두 개의 인터페이스 168.1과 168.2을 사용하여 두 네트워크에 모두 연결됩니다. A의 IP는 192.168.1.5입니다. C에는 192.168.2.5가 있습니다. 그리고 B는 두 네트워크 1.6과 2.6 모두에 IP를 가지고 있습니다. A가 C와 대화하게 하려면 어떻게 해야 할까요? 기본적으로 A에서 핑 2.5를 시도하면 네트워크에 연결할 수 없다고 표시됩니다. 그리고 이제 우리는 그 이유를 알고 있습니다. 호스트 A는 192,168.2. 네트워크에 도달하는 방법을 모릅니다. 우리는 호스트 A에게 네트워크 2의 문 또는 게이트웨이가 호스트 B를 통과한다고 알려주어야 합니다. 라우팅 테이블 항목을 추가하여 이를 수행합니다. 192.168.1.6게이트웨이를 통해 네트워크 192.168.2 에 액세스하기 위한 라우트를 추가합니다. 패킷이 호스트 C를 통과하는 경우 호스트 C는 호스트 A에 응답을 다시 보내야 합니다.
호스트 C가 192.168.1에 있는 호스트 A에 도달하려고 할 때, 동일한 문제에 직면하게 됩니다. 따라서 라우터 역할을 하는 호스트 B를 통해 호스트 A에 도달할 수 있음을 호스트 C에게 알려주어야 합니다. 따라서 호스트 C의 라우팅 테이블에 유사한 항목을 추가합니다. 이번에는 네트워크 192.168.1.0에 도달하려면 192.168.2.6에 있는 호스트 B와 대화하라고 말합니다. 지금 핑을 시도하면 더 이상 네트워크에 연결할 수 없다는 오류 메시지가 표시되지 않습니다. 이는 라우팅 항목이 옳다는 것을 의미합니다.
그러나 우리는 여전히 어떤 응답도 받지 못합니다. default로 Linux에서는 패킷이 한 인터페이스에서 다음 인터페이스로 전달되지 않습니다. 예를 들어 호스트 B의 eth0에서 수신된 패킷은 eth1을 통해 다른 곳으로 전달되지 않습니다. 보안상의 이유 때문입니다. 예를 들어 eth0이 개인 네트워크에 연결되어 있고 eth1이 공용 네트워크에 연결되어 있는 경우, 명시적으로 허용하지 않는 한 공용 네트워크의 어느 누구도 개인 네트워크로 메시지를 쉽게 보낼 수 없습니다.
그러나 지금 예제의 경우 둘 다 사설 네트워크이고 둘 사이의 통신을 가능하게 하는 것이 안전하다는 것을 알고 있으므로 호스트 B가 한 네트워크에서 다른 네트워크로 패킷을 전달하도록 허용할 수 있습니다. 호스트가 인터페이스 간에 패킷을 전달할 수 있는지 여부는 파일 proc/sys/net/ipv4/ip_forward에서 이 시스템의 설정에 따라 결정됩니다. default로 이 파일의 값은 0으로 설정되어 있으며, 이는 전달이 없음을 의미합니다. 이것을 1로 설정하면 핑이 통과하는 것을 볼 수 있습니다. 이제 이 값을 설정하는 것만으로는 재부팅 후에도 변경 사항이 지속되지 않는다는 점을 기억하십시오. 변경사항이 재부팅 후에도 지속되기 위해서는 etc/sys/control.conf파일 에서 동일한 값을 수정해야 합니다.
ip link는 호스트의 수정 인터페이스를 나열하는 것입니다. ip addr 커맨드는 해당 인터페이스에 할당된 IP 주소를 확인하는 것입니다. ip addr add 커맨드는 인터페이스에 IP 주소를 설정하는 데 사용됩니다. 이제 이러한 커맨드를 사용하여 변경한 사항은 다시 시작할 때까지만 유효합니다. 이러한 변경 사항을 유지하려면 etc/network/interfaces 파일에서 설정해야 합니다. ip route 또는 단순히 route 커맨드를 사용하여 라우팅 테이블을 볼 수 있습니다. 그리고 ip route add 커맨드는 라우팅 테이블에 항목을 추가하는 데 사용됩니다. 마지막으로 라우터로 구성된 호스트로 작업하는 경우 호스트에서 IP 전달이 활성화되어 있는지 확인하는 커맨드를 기억하십시오. cat /proc/sys/net/ipv4/ip_forward입니다.
Prerequisite - DNS
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이라고 합니다.
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할 수 없어야 합니다.
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에서 사용할 수 있습니다. 필요에 따라 이들 각각을 많은 하위 도메인으로 추가로 나눌 수 있습니다. 따라서 트리 구조가 형성되는 것을 볼 수 있습니다.
조직 내에서 이러한 도메인 이름(예: apps.google.com)에 도달하려고 하면 요청이 먼저 조직의 내부 DNS 서버에 도달합니다. 앱이나 Google이 누구인지 모르기 때문에 요청을 인터넷으로 전달합니다. 인터넷에서 apps.google.com을 제공하는 서버의 IP 주소는 여러 DNS 서버의 도움을 받아 확인할 수 있습니다. route DNS 서버는 요청을 보고 .coms를 제공하는 DNS 서버를 가리킵니다. .com DNS 서버는 우리의 요청을 보고 우리를 Google에 전달합니다. 그리고 Google의 DNS 서버는 앱의 애플리케이션을 제공하는 서버의 IP를 제공합니다. 향후의 모든 확인 속도를 높이기 위해 조직의 DNS 서버는 일정 시간(일반적으로 몇 초에서 최대 몇 분) 동안 이 IP를 캐싱하도록 선택할 수 있습니다. 이렇게 하면 매번 전체 프로세스를 다시 거칠 필요가 없습니다. 그래서 그것은 이제 확인 가능합니다.
당신의 회사는 어떻습니까? 회사도 비슷한 구조를 가질 수 있습니다. 예를 들어 회사의 이름을 mycompany.com으로 지정하고 각 용도에 대해 여러 하위 도메인을 가질 수 있습니다. 외부용 웹사이트용 www, 조직의 메일에 액세스하기 위한 mail.mycompany.com, 저장소에 액세스하기 위한 drive, 급여 애플리케이션에 액세스하기 위한 pay 또는 company.com, HR 애플리케이션에 액세스하기 위한 hr 등이 있습니다. 이들 모두는 조직의 내부 DNS 서버에서 구성됩니다. 이 모든 것을 논의한 이유는 etc/resolv.conf 파일의 다른 항목을 이해하기 위해서입니다. 이 파일은 호스트에 사용할 DNS 서버를 구성한 파일입니다. 이를 통해 Web과 같은 이름만으로 조직의 서버를 확인할 수 있었습니다. 이제 web.mycompany.com 또는 db.mycompany.com 등과 같은 더 많은 표준 도메인 이름을 도입했습니다.
이제 웹을 ping하면 더 이상 응답을 받을 수 없습니다. 물론 이것은 우리가 web에 ping을 시도하고 있지만 내 DNS 서버에서 web이라는 이름에 대한 기록이 없기 때문입니다. 대신 web.mycompany.com이므로 web.mycompany.com을 사용해야 합니다. 이제 회사 외부의 누군가가 웹 서버에 액세스하려는 경우 web.mycompany.com을 사용해야 한다는 것을 이해할 수 있습니다.
그러나 우리 회사 내에서 우리는 웹 서버의 이름을 web으로 간단히 지정하기를 원합니다. 가족의 다른 구성원을 이름으로 부르는 것과 같습니다. 내 web.mycompany.com을 확인하도록 web을 지정하려면 어떻게 해야 합니까? "web이라고 하면 web.mycompany.com을 의미합니다."라고 말하고 싶을 것입니다. 이를 위해서는 search라는 호스트의 etc/resolv.conf 파일에 항목을 만들고 추가할 도메인 이름을 지정하면 됩니다. 다음에 web에 ping을 시도하면 실제로 web.mycompany.com을 시도하는 것을 볼 수 있습니다. 이제 호스트는 이와 같이 쿼리에 도메인을 지정한 경우 검색 도메인을 제외할 만큼 충분히 지능적입니다.
이와 같은 추가 search 도메인을 제공할 수도 있습니다. 따라서 "web"이라고 하면 web.mycompany.com 또는 web.prod.mycompany.com을 의미합니다. 따라서 호스트 이름을 찾을 때 호스트는 이러한 모든 도메인 이름을 검색하려고 시도합니다.
Record Types
마지막으로 레코드 유형에 대한 설명입니다. 그렇다면 레코드는 DNS 서버에 어떻게 저장됩니까? 호스트 이름에 IP를 저장한다는 것을 알고 있습니다. 그것은 A 레코드로 알려져 있습니다. IPv6을 호스트 이름에 저장하는 것을 quad-A records라고 합니다. 한 이름을 다른 이름에 매핑하는 것을 CNAME 레코드라고 합니다. 예를 들어 음식 배달 서비스와 같이 동일한 애플리케이션에 대해 여러 개의 별칭이 있을 수 있습니다. CNAME 레코드가 사용되는 곳입니다. 이름 대 이름 매핑입니다. 더 많은 것이 있지만 지금은 그것이 우리가 살펴볼 전부입니다.
Networking Tools
ping이 항상 DNS 확인을 테스트하는 올바른 tool은 아닐 수 있습니다. nslookup과 같은 몇 가지 다른 툴도 있습니다. nslookup을 사용하여 DNS 서버에서 호스트 이름을 쿼리할 수 있습니다. 그러나 nslookup은 로컬 etc/hosts 파일의 항목을 고려하지 않는다는 점을 기억하십시오. 따라서 웹 애플리케이션에 대한 로컬 etc/hosts 파일에 항목을 추가하고 해당 웹 애플리케이션에 대해 nslookup을 시도하면 찾을 수 없습니다. 웹 애플리케이션에 대한 항목이 DNS 서버에 있어야 합니다. Nslookup은 DNS 서버만 쿼리합니다.
$ nslookup www.google.com
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: www.google.com
Address: 172.217.18.4
Name: www.google.comdig도 마찬가지입니다. dig는 DNS 이름 확인을 테스트하는 또 다른 유용한 tool입니다. 서버에 저장된 것과 유사한 형식으로 자세한 내용을 반환합니다.
$ dig www.google.com
; <<>> DiG 9.11.3-1 ...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8738
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.google.com. IN A
;; ANSWER SECTION:
www.google.com. 63 IN A 216.58.206.4
;; Query time: 6 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)Prerequisite - CoreDNS
DNS 서버 전용 서버와 서버의 항목으로 구성할 일련의 IP가 제공됩니다. 시중에는 많은 DNS 서버 솔루션이 있습니다. 이 강의에서는 특정 솔루션인 CoreDNS에 중점을 둘 것입니다.
그렇다면 CoreDNS는 어떻게 얻습니까? CoreDNS 바이너리는 Github 릴리스 페이지에서 또는 도커 이미지로 다운로드할 수 있습니다. 전통적인 방법으로 갑시다. curl 또는 wget을 사용하여 바이너리를 다운로드합니다. 그리고 그것을 추출하십시오. coredns 실행 파일을 얻습니다.
실행 파일을 실행하여 DNS 서버를 시작하십시오. 디폴트로 DNS 서버의 기본 포트인 포트 53에서 수신 대기합니다.
이제 호스트 네임 매핑에 대한 IP를 지정하지 않았습니다. 이를 위해 몇 가지 구성을 제공해야 합니다. 여러 가지 방법이 있습니다. 우리는 하나를 볼 것입니다. 먼저 모든 항목을 DNS 서버의 /etc/hosts 파일에 넣습니다.
그런 다음 해당 파일을 사용하도록 CoreDNS를 구성합니다. CoreDNS는 Corefile이라는 파일에서 구성을 로드합니다. 다음은 /etc/hosts 파일에서 호스트 이름 매핑에 대한 IP를 가져오도록 CoreDNS에 지시하는 간단한 구성입니다. DNS 서버가 실행되면 이제 서버의 /etc/hosts 파일에서 IP와 이름을 선택합니다.
CoreDNS는 플러그인을 통해 DNS 항목을 구성하는 다른 방법도 지원합니다. 이후 섹션에서 Kubernetes에 사용되는 플러그인을 살펴보겠습니다.
아래에서 CoreDNS에 대해 자세히 알아보세요.
https://github.com/kubernetes/dns/blob/master/docs/specification.md
