Udemy CKA 강의 정리 222: DNS in kubernetes

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.

---

이 강의에서는 Kubernetes 클러스터의 DNS에 대해 설명합니다. DNS를 처음 사용하는 경우 DNS에 대한 필수 컴포넌트 섹션을 살펴보세요.

여기에서 DNS는 무엇입니까? 호스트 NSlookup, dig 유틸리티 및 AC 이름 등과 같은 다양한 유형의 DNS 레코드와 같은 DNS 작업에 사용되는 tool은 무엇입니까? 또한 Core DNS를 사용하여 자체 DNS 서버를 설정하는 방법도 살펴보았습니다. 이 강의에서는 어떤 오브젝트에 어떤 이름이 할당되는지, 서비스 DNS 레코드가 무엇인지, 파드 DNS 레코드가 무엇인지, 한 파드에서 다른 파드에 도달할 수 있는 다양한 방법은 무엇인지 알아봅니다. 그리고 다음 강의에서는 Kubernetes가 클러스터에서 DNS를 구현하는 방법을 살펴보겠습니다.

따라서 일부 파드와 서비스가 배포된 세 노드 Kubernetes 클러스터가 있습니다. 각 노드에는 할당된 노드 이름과 IP 주소가 있습니다. 클러스터의 노드 이름과 IP 주소는 아마도 조직의 DNS 서버에 등록되어 있을 것입니다. 이제 어떻게 관리됩니까? 누가 액세스합니까? 이 강의에서는 관심이 없습니다. 이 강의에서는 클러스터 내에서, 파드 및 서비스와 같은 클러스터에서 서로 다른 컴포넌트 간에 DNS 확인에 대해 설명합니다.

Kubernetes는 클러스터를 설정할 때 default로 built-in DNS 서버를 배포합니다. Kubernetes를 수동으로 설정하는 경우에는 직접 설정해야 합니다. 이것이 어떻게 이루어지고 어떻게 구성되는지는 다음 강의에서 살펴보겠습니다. 이 강의에서는, 파드가 클러스터 내의 다른 파드 및 서비스를 해결하는 데 어떻게 도움이 되는지 살펴보겠습니다. 그래서 우리는 노드에 대해 별로 신경쓰지 않습니다. 우리는 클러스터 내의 파드와 서비스에만 집중합니다. 클러스터 네트워킹이 올바르게 설정되어 있는 한 이 섹션에서 지금까지 배운 best practices와 모든 파드 및 서비스에 따라 고유한 IP 주소를 얻고 서로 연결할 수 있습니다.

두 개의 파드과 하나의 서비스로 시작해 보겠습니다. 왼쪽에는 IP가 10 2 44.105로 설정된 테스트 파드가 있고 오른쪽에는 IP가 10 2 44.2.5로 설정된 웹 파드가 있습니다. 그들의 IP를 보면 아마도 두 개의 다른 노드에서 호스팅되고 있다고 추측할 수 있지만 실제로는 중요하지 않습니다. DNS에 관한 한 모든 파드와 서비스는 IP 주소를 사용하여 서로 도달할 수 있다고 가정합니다. 테스트 파드에서 웹 서버에 액세스할 수 있도록 서비스를 작성합니다. 우리는 그것을 웹 서비스라고 부릅니다. 서비스는 IP 10 10737.188을 받습니다. 서비스가 생성될 때마다 Kubernetes DNS 서비스는 서비스에 대한 레코드를 생성합니다. 서비스 이름을 IP 주소에 매핑하므로 클러스터 내에서 이제 모든 파드가 해당 서비스 이름을 사용하여 이 서비스에 도달할 수 있습니다. 이전에 네임스페이스에 대해 이야기한 것을 기억하세요. 네임스페이스 내의 모든 사람은 이름으로만 서로를 부르고 다른 네임스페이스에 있는 사람을 부르려면 전체 이름을 사용합니다. 이 경우 테스트 파드과 웹 파드 및 관련 서비스가 모두 default 네임스페이스인 동일한 네임스페이스에 있으므로 서비스 이름 web-service만 사용하여 테스트 파드에서 웹 서비스에 간단히 도달할 수 있었습니다.

웹 서비스가 Apps라는 별도의 네임스페이스에 있다고 가정해 보겠습니다. 그런 다음 default 네임스페이스에서 참조하려면 웹 서비스라고 말해야 합니다. 앱. 서비스의 성은 이제 네임스페이스의 이름입니다. 여기서 Web Service는 서비스의 이름이고 Apps는 네임스페이스의 이름입니다. 각 namespace에 대해 DNS 서버는 하위 도메인을 만듭니다. 모든 서비스는 SVC라는 또 다른 하위 도메인으로 함께 그룹화됩니다.

자세히 살펴보겠습니다. 웹 서비스는 서비스의 이름이고 앱은 namespace의 이름입니다. 각 네임스페이스에 대해 DNS 서버는 해당 이름으로 하위 도메인을 만듭니다. 따라서 네임스페이스에 대한 모든 파드 및 서비스는 네임스페이스 이름의 하위 도메인 내에서 함께 그룹화됩니다. 모든 서비스는 SVC라는 또 다른 하위 도메인으로 그룹화됩니다. 따라서 webservice.apps.svc라는 이름으로 애플리케이션에 연결할 수 있습니다. 마지막으로 모든 서비스와 파드은 default로 cluster.local로 설정된 클러스터의 경로 도메인으로 함께 그룹화됩니다. 따라서 URL webservice.apps.svc.cluster.local을 사용하여 서비스에 액세스할 수 있으며 이는 서비스의 정규화된 도메인 이름입니다. 이것이 클러스터 내에서 서비스가 해결되는 방식입니다. 파드는 어떻습니까? 파드에 대한 레코드는 default로 생성되지 않지만 명시적으로 활성화할 수 있습니다. 다음 강의에서 보도록 하겠습니다. 활성화되면 파드에 대한 레코드도 생성됩니다. 하지만 파드 이름을 사용하지 않습니다. 각 파드에 대해 Kubernetes는 IP 주소의 점을 대시로 대체하여 이름을 생성합니다. namespace은 동일하게 유지되고 유형은 pod로 설정됩니다. 경로 도메인은 항상 cluster.local입니다.

마찬가지로 default 네임스페이스의 테스트 파드는 IP가 대시 호스트 이름인 10-244-1-5로 변환되고 네임스페이스가 default값으로 설정된 DNS 서버에서 레코드를 가져옵니다. 유형은 파드 이고 그 경로는 cluster.local입니다. 이것은 포드의 IP 주소로 귀결됩니다.