kubernetes CKA study (29) - IP Address Management - Weave, Service-Networking, DNS in kubernetes, CoreDNS in kubernetes
kubernetes CKA study
IP Address Management - Weave
IP address management와 Kubernetes는 어떻게 작동할까요? 이 섹션에서는 네트워크의 노드에 할당된 IP 주소에 대해 설명하지 않습니다. 자체적으로 또는 외부 IPAM 솔루션을 사용하여 이를 관리할 수 있습니다.
이 섹션에서는 노드의 가상 브리지 네트워크에 IP 서브넷을 할당하는 방법과 파드에 IP를 할당하는 방법에 대해 설명합니다. 이 정보는 어디에 저장됩니까? 그리고 누가 중복된 IP가 할당되지 않았는지 확인할 책임이 있을까요?
"누가?"부터 시작하겠습니다. CNI가 표준을 정의하므로 CNI에게 물어봅시다. CNI는 컨테이너에 IP를 할당하는 것은 네트워크 솔루션 제공업체인 CNI 플러그인의 책임이라고 말합니다. 우리가 이전에 만든 basic 플러그인을 기억하시나요? 우리는 실제로 이 플러그인 내에서 IP 주소 할당을 담당했습니다. 컨테이너 네트워크 네임스페이스에 IP를 할당하는 섹션이 있습니다.
그러나 이러한 IP를 어떻게 관리해야 할까요? 이제, 쿠버네티스는 우리가 어떻게 하는지 신경쓰지 않습니다. 중복된 IP를 할당하지 않고 제대로 관리하는 방식으로 진행하면 됩니다. IP 목록을 파일에 저장하고 이 파일을 제대로 관리하는 데 필요한 코드가 스크립트에 있는지 확인하는 것이 쉬운 방법입니다. 이 파일은 각 호스트에 배치되고 해당 노드의 부품 IP를 관리합니다. 우리의 스크립트에서 직접 코딩하는 대신, CNI에는 이 작업을 아웃소싱할 수 있는 두 개의 플러그인이 builtin되어 있습니다. 이 경우 각 호스트의 IP 주소를 로컬로 관리하기 위해 수행한 방식을 구현하는 플러그인이 호스트 로컬 플러그인입니다. 그러나 스크립트에서 플러그인을 호출하는 것은 여전히 우리의 책임입니다. 그렇지 않으면 스크립트를 동적으로 만들어 다양한 종류의 플러그인을 지원할 수 있습니다.
CNI configuration 파일에는 사용할 플러그인 유형, 서브넷 및 경로를 지정할 수 있는 IPAM이라는 섹션이 있습니다. 이러한 세부 정보는 매번 호스트 로컬을 사용하도록 하드 코딩하는 대신 적절한 플러그인을 호출하기 위해 스크립트에서 읽을 수 있습니다. 네트워크 솔루션 공급자에 따라 이를 다르게 수행합니다.
Weaveworks가 IP 주소를 어떻게 관리하는지 알아봅시다. 이전 연습 테스트에서 Weave가 할당한 IP 중 일부를 본 적이 있습니다. default로 Weave는 전체 네트워크에 대해 IP 범위 10.32.0.0/12를 할당합니다. 네트워크 IP 범위는 10.32.0.1 ~ 10.47.255.254입니다. 네트워크의 파드에 사용할 수 있는 IP는 약 백만 개입니다. 이 범위에서 peers는 IP 주소를 동일하게 분할하기로 결정하고 각 노드에 한 부분을 할당합니다. 이 노드에서 생성된 파드는 이 범위의 IP를 가집니다. 물론 이러한 범위는 Weave 플러그인을 클러스터에 배포하는 동안 이전의 추가 옵션으로 구성할 수 있습니다.
테스트 문제 기록
What is the Networking Solution used by this cluster? (네트워킹 솔루션이 뭔지?)
ls /etc/cni/net.d/
Identify the name of the bridge network/interface created by weave on each node.
(각 노드에서 weave로 생성된 브리지 네트워크/인터페이스의 이름)
ip link
What is the POD IP address range configured by weave? (Weave에서 구성한 POD IP 주소 범위)
ip addr show weave
What is the default gateway configured on the PODs scheduled on node01? (node01에 예약된 POD에 구성된 기본 게이트웨이)
ssh node01 후 ip route
Service-Networking
이전 강의에서는 파드 네트워킹에 대해 이야기했습니다. 각 노드 내에서 브리지 네트워크를 생성하는 방법, 파드가 네임스페이스를 생성하는 방법, 파드가 이러한 네임스페이스에 연결되는 방법, 파드가 해당 노드에 할당된 이 서브넷 내에서 브리지 네트워크에 할당된 IP 주소를 얻는 방법을 살펴보고 route나 다른 오버레이 기술을 통해 우리는 다른 노드에 있는 파드들이 서로 대화하도록 하여 모든 파드들이 서로 연결될 수 있는 큰 가상 네트워크를 형성할 수 있다는 것을 보았습니다.
이제 파드가 서로 직접 통신하도록 구성하는 경우는 거의 없습니다. 다른 파드에서 호스팅되는 서비스에 액세스하려면 항상 서비스를 사용해야 합니다. 다양한 종류의 서비스에 대해 간단히 요약해 보겠습니다. blue 파드가 orange 파드에 접근할 수 있도록, 우리는 orange 서비스를 만듭니다. orange 서비스는 IP 주소와 할당된 이름을 가져옵니다. 이제 blue 파드는 orange 서비스 IP 또는 해당 이름을 통해 orange 파드에 액세스할 수 있습니다. 우리는 이번 강의에서 name resolution에 대해 이야기할 것입니다.
지금은 IP 주소에만 집중합시다. blue과 orange 보드가 같은 노드에 있습니다. 다른 파드나 다른 노드에서 액세스하는 것은 어떻습니까? 서비스가 생성되면 파드가 어떤 노드에 있는지에 관계없이 클러스터의 모든 파드에서 서비스에 액세스할 수 있습니다. 파드가 노드에서 호스팅되는 동안 서비스는 클러스터 전체에서 호스팅됩니다. 이 서비스는 특정 노드에 바인딩되지 않지만 클러스터 내에서만 액세스할 수 있습니다. 이러한 유형의 서비스를 클러스터 IP라고 합니다. orange 파드가 클러스터 내에서만 액세스할 수 있는 데이터베이스 애플리케이션을 호스팅하고 있었다면 이러한 유형의 서비스는 제대로 작동합니다.
Service Types
<clusterIP.yaml>
apiVersion: v1
kind: Service
metadata:
name: local-cluster
spec:
ports:
- port: 80
targetPort: 80
selector:
app: nginx
<nodeportIP.yaml>
apiVersion: v1
kind: Service
metadata:
name: nodeport-wide
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
selector:
app: nginx예를 들어, purple 파드가 클러스터 외부에서 파드의 애플리케이션에 액세스할 수 있도록 웹 애플리케이션을 호스팅하고 있었다고 가정해 보겠습니다. 노드 포트 유형의 다른 서비스를 생성합니다. 또한 이 서비스는 할당된 IP 주소를 가져오고 클러스터 IP와 마찬가지로 작동합니다. 다른 모든 파드에서는 IP를 사용하여 서비스에 액세스할 수 있습니다.
또한 클러스터의 모든 노드에 있는 포트에 애플리케이션이 노출됩니다. 이렇게 하면 외부 사용자 또는 응용프로그램이 서비스에 액세스할 수 있습니다. 이것이 이번 강의의 주제입니다. 우리는 파드보다는 서비스에 더 초점을 맞추고 있습니다. 서비스는 어떻게 이러한 IP 주소를 가져오고 클러스터의 모든 노드에서 이러한 IP 주소를 사용할 수 있을까요? 각 노드의 포트를 통해 외부 사용자가 서비스를 이용할 수 있는 방법은 무엇인가요? 누가, 어떻게, 그리고 어디에서 그것을 볼 수 있을까요? 그럼 시작해볼게요. 백지상태에서 시작합시다.
세 노드 클러스터가 있고 파드나 서비스는 아직 없습니다. 우리는 모든 Kubernetes 노드가 파드를 만드는 kubelet 프로세스를 실행한다는 것을 알고 있습니다. 각 노드의 각 kubelet 서비스는 kube API 서버를 통해 클러스터의 변경 사항을 모니터링하며, 새로운 파드가 생성될 때마다 노드에 파드를 생성합니다. 그런 다음 CNI 플러그인을 호출하여 해당 파드에 대한 네트워킹을 구성합니다.
비슷하게, 각 노드는 Kube-proxy로 알려진 또 다른 컴포넌트를 실행합니다. Kube-proxy는 Kube API 서버를 통해 클러스터의 변화를 감시하고, 새로운 서비스가 생성될 때마다 Kube-proxy가 실행됩니다.
파드와 달리 서비스는 각 노드에 생성되거나 각 노드에 할당되지 않습니다. 서비스는 클러스터 차원의 개념입니다. 클러스터의 모든 노드에 존재합니다. 사실, 그들은 전혀 존재하지 않습니다. 서비스의 IP를 실제로 수신하는 서버나 서비스가 없습니다. 파드에는 컨테이너가 있고 컨테이너에는 인터페이스와 Ip가 할당된 네임스페이스가 있습니다. 서비스와 함께라면, 그런 것은 존재하지 않는다. 서비스에 대한 프로세스, 네임스페이스 또는 인터페이스가 없습니다. 그것은 단지 가상의 물체일 뿐입니다. 그렇다면 그들은 어떻게 IP 주소를 얻고 우리는 어떻게 서비스를 통해 파드의 애플리케이션에 액세스할 수 있을까요?
To create the service
$ kubectl create -f clusterIP.yaml
service/local-cluster created
$ kubectl create -f nodeportIP.yaml
service/nodeport-wide createdTo get the Additional Information
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 1m 10.244.1.3 node01 <none> <noKubernetes에서 서비스 오브젝트를 만들면 미리 정의된 범위의 IP 주소가 할당됩니다. 이 노드에서 실행 중인 kube-proxy 컴포넌트는 해당 IP 주소를 가져오고 클러스터의 각 노드에 전달 rule을 생성합니다. 즉, 서비스의 IP인 이 IP로 오는 트래픽은 파드의 IP로 가야 합니다. 일단 서비스가 설치되면 파드가 서비스의 IP에 도달하려고 할 때마다 서비스는 클러스터의 모든 노드에서 액세스할 수 있는 파드의 IP 주소로 전달됩니다. IP뿐만 아니라 IP와 포트의 조합이라는 점을 기억하세요. 서비스가 생성되거나 삭제될 때마다 kube-proxy 컴포넌트는 이러한 rule을 생성하거나 삭제합니다.
그렇다면 이 rule들은 어떻게 만들어졌을까요? kube-proxy는 각 서비스에 대해 포트에서 수신 대기하는 사용자 공간과 같은 다양한 방식을 지원하며, IPVS rule을 만들어 파드에 대한 연결을 프록시합니다. 우리에게 익숙한 것은 IP 테이블을 사용하는 것입니다. 프록시 모드는 kube-proxy 서비스를 구성하는 동안 프록시 모드 옵션을 사용하여 설정할 수 있습니다. 이 옵션을 설정하지 않으면 default로 IP 테이블로 설정됩니다.
To check the Service Cluster IP Range
$ ps -aux | grep kube-apiserver
--secure-port=6443 --service-account-key-file=/etc/kubernetes/pki/sa.pub --
service-cluster-ip-range=10.96.0.0/12이제 IP 테이블이 kube-proxy에 의해 구성되는 방법과 노드에서 이를 볼 수 있는 방법을 살펴보겠습니다. 노드 1에 배치된 DB라는 파드가 있습니다. IP 주소는 10.244.1.2입니다. 클러스터 내에서 이 파드를 사용할 수 있도록 클러스터 IP 유형의 서비스를 생성합니다. 서비스가 생성되면 Kubernetes는 서비스에 IP 주소를 할당합니다. 10.103.132.104로 설정됩니다. 이 범위는 서비스 클러스터 IP 범위라고 하는 Kube API 서버 옵션에 지정되며, default로 10.0.0/24로 설정됩니다. 이 경우, Kube API 서버 옵션을 보면 10.96.0.0/12로 설정되어 있습니다. 이를 통해 10.96.0.0에서 10.111.255.255 사이의 서비스 IP를 얻을 수 있습니다. 여기서 언급해야 할 상대적인 사항은 POD 네트워킹을 설정할 때 10244.0.0/16 범위의 파드 네트워크 CIDR을 제공하여 1024400에서 10244.255.255 사이의 파드 IP 주소를 제공했다는 것입니다. 제가 이 문제를 제기한 이유는 각 네트워크에 대해 어떤 범위를 지정하든 중복되지 않아야 하기 때문입니다.
To check the rules created by kube-proxy in the iptables
$ iptables -L -t nat | grep local-cluster
KUBE-MARK-MASQ all -- 10.244.1.3 anywhere /* default/local-cluster: */
DNAT tcp -- anywhere anywhere /* default/local-cluster: */ tcp to:10.244.1.3:80
KUBE-MARK-MASQ tcp -- !10.244.0.0/16 10.101.67.139 /* default/local-cluster: cluster IP */ tcp dpt:http
KUBE-SVC-SDGXHD6P3SINP7QJ tcp -- anywhere 10.101.67.139 /* default/local-cluster: cluster IP */ tcp dpt:http
KUBE-SEP-GEKJR4UBUI5ONAYW all -- anywhere anywhere /* default/local-cluster: */이 경우에는 그렇지 않습니다. 이 두 가지 모두 사용할 수 있는 전용 IP 범위가 있어야 합니다. 파드와 서비스에 동일한 IP 주소가 할당되는 경우는 없어야 합니다. 서비스로 돌아가면 서비스가 10.103.132.104의 IP 주소를 얻게 됩니다. IP 테이블 넷 테이블 출력에서 Kube-proxy에 의해 생성된 rule을 확인할 수 있습니다. Kube-proxy에 의해 생성된 모든 rule에 서비스 이름이 포함된 주석이 있으므로 서비스 이름을 검색합니다. 이러한 rule은 서비스의 IP인 포트 3306의 IP 주소 10103132.104로 가는 트래픽은 대상 주소가 10244.1.2로 변경되고 파드의 IP인 포트 3306이 변경되어야 함을 의미합니다. 이 작업은 IP 테이블에 Dnet rule을 추가하여 수행됩니다. 마찬가지로 노드 포트 유형의 서비스를 생성할 때 Kube-proxy는 모든 노드의 포트에서 들어오는 모든 트래픽을 해당 백엔드 파드로 전달하는 IP 테이블 rule을 생성합니다.
To check the logs of kube-proxy
$ cat /var/log/kube-proxy.log또한 kube-proxy 로그 자체에서 이러한 항목을 생성하는 것을 볼 수 있습니다. 로그에서 어떤 프록시를 사용하는지 확인할 수 있습니다. 이 경우에는 IP 테이블이며, 데이터베이스에 대한 새 서비스를 추가할 때 항목을 추가합니다. 이 파일의 위치는 설치에 따라 다를 수 있습니다. 이러한 항목이 표시되지 않으면 verbosity level도 확인해야 합니다. 그게 바로 서비스 네트워킹에 관한 것입니다.
테스트 문제 기록
What network range are the nodes in the cluster part of?
ip a | grep eth0
What is the range of IP addresses configured for PODs on this cluster? ( 클러스터의 POD에 대해 구성된 IP 주소 범위)
kubectl logs weave-net-65mv8 -n kube-system | grep ipalloc-range
What is the IP Range configured for the services within the cluster? (클러스터 내의 서비스에 대해 구성된 IP 범위)
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep cluster-ip-range
What type of proxy is the kube-proxy configured to use?
kube-proxy는 어떤 유형의 프록시를 사용하도록 구성되어 있나요?
k logs kube-proxy-r9c77 -n kube-system
테스트 통과 완료
DNS in kubernetes
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 주소로 귀결됩니다.
CoreDNS in kubernetes
2개의 IP 주소가 있는 2개의 파드이 주어졌다고 가정하면 어떻게 하시겠습니까? DNS에 대한 필수 강의에서 배운 내용을 기반으로 서로를 해결하는 쉬운 방법은 각각의 etc 호스트 파일에 항목을 추가하는 것입니다. 첫 번째 파드에서 두 번째 파드인 web은 10.244.2.5에 있고 두 번째 파드에서는 첫 번째 파드인 test가 10.244.1.5에 있다고 말할 수 있습니다. 물론 클러스터에 수천 개의 파드가 있고 매분 수백 개가 생성 및 삭제되는 경우 이는 적합한 솔루션이 아닙니다.
따라서 이러한 항목을 중앙 DNS 서버로 이동합니다. 그런 다음 etc/resolv.conf 파일에 항목을 추가하고 이름 서버가 DNS 서버의 IP 주소(이 경우 10.96.0.10)에 있음을 지정하여 이러한 파드를 DNS 서버로 지정합니다. 새 파드가 생성될 때마다 다른 파드가 새 파드에 액세스하고 파드의 etc/resolv.conf 파일이 DNS 서버를 가리키도록 구성할 수 있도록 해당 파드의 DNS 서버에 레코드를 추가합니다. 새 파드가 클러스터의 다른 파드를 확인할 수 있도록 합니다. 이것은 쿠버네티스가 수행하는 방식과 비슷하지만 이전 강의에서 본 것처럼 파드 이름을 IP 주소에 매핑하기 위해 파드에 대한 유사한 항목을 생성하지 않습니다. 서비스를 위해 그렇게합니다.
파드의 경우 파드의 IP 주소에서 점을 대시로 대체하여 호스트 이름을 구성합니다. Kubernetes는 동일한 방식으로 DNS를 구현합니다. 클러스터 내에 DNS 서버를 배포합니다. 버전 1.12 이전에는 Kubernetes에 의해 구현된 DNS 서버가 Kube DNS로 알려졌으며 Kubernetes 버전 1.12에서는 권장 DNS 서버가 CoreDNS입니다. 필수 강의 중 하나에서 CoreDNS를 간략하게 살펴보았습니다. 그렇다면 클러스터에서 CoreDNS는 어떻게 설정됩니까? coreDNS 서버는 Kubernetes 클러스터의 Kube 시스템 네임스페이스에 파드로 배포됩니다. replicas 세트의 일부로 중복성을 위해 두 개의 파드로 배포됩니다. 실제로 배포 내의 replicas 세트이지만 실제로는 중요하지 않습니다. 하지만 이 강의에서는 CoreDNS를 파드로 볼 것입니다.
이 파드는 CoreDNS 실행 파일을 실행합니다. CoreDNS를 직접 배포할 때 실행한 것과 동일한 실행 파일입니다. CoreDNS에는 configuration 파일이 필요합니다. 우리의 경우 Core file이라는 파일을 사용했고 Kubernetes도 마찬가지입니다. etc/coredns에 위치한 Core File이라는 파일을 사용합니다. 이 파일에는 여러 플러그인이 구성되어 있습니다.
플러그인은 오류 처리, 상태 보고, 메트릭 모니터링, 현금 등을 위해 구성됩니다. CoreDNS가 Kubernetes와 작동하도록 하는 플러그인은 Kubernetes 플러그인입니다. 그리고 클러스터의 최상위 도메인 이름이 설정되는 곳입니다. 이 경우 cluster.local입니다. 따라서 CoreDNS DNS 서버의 모든 레코드는 이 도메인에 속합니다.
Kubernetes 플러그인에는 여러 가지 옵션이 있습니다. 여기에서 볼 수 있는 파드 옵션은 클러스터의 파드에 대한 레코드 생성을 담당합니다. IP를 파선 형식으로 변환하여 각 파드에 대해 생성되는 레코드에 대해 이야기했음을 기억하세요. default로 비활성화되어 있지만 여기에서 이 항목을 사용하여 활성화할 수 있습니다.
예를 들어 파드가 www.google.com에 도달하려고 한다고 말하면 DNS 서버가 해결할 수 없는 모든 레코드는 CoreDNS 파드 등 resolv.conf 파일에 지정된 이름 서버로 전달됩니다. etc/resolv.conf 파일은 Kubernetes 노드에서 이름 서버를 사용한다고 합니다. 또한 이 코어 파일은 configmap 오브젝트로 파드에 전달됩니다. 이렇게 하면 이 configuration을 수정해야 하는 경우 configmap 오브젝트를 편집할 수 있습니다. 이제 적절한 Kubernetes 플러그인을 사용하여 CoreDNS 파드를 실행하고 있습니다. Kubernetes 클러스터에서 새로운 파드 또는 서비스를 감시하고 파드 또는 서비스가 생성될 때마다 데이터베이스에 레코드를 추가합니다.
다음 단계는 Pod가 CoreDNS 서버를 가리키는 것입니다. 파드는 DNS 서버에 도달하기 위해 어떤 주소를 사용할까요? CoreDNS 솔루션을 배포할 때 클러스터 내의 다른 컴포넌트에서 사용할 수 있도록 서비스도 생성합니다. 서비스 이름은 default로 kube-dNS로 지정됩니다. 이 서비스의 IP 주소는 파드에서 이름 서버로 구성됩니다. 이제 직접 구성할 필요가 없습니다. 파드의 DNS config은 파드가 생성될 때 Kubernetes에 의해 자동으로 수행됩니다.
이를 담당하는 Kubernetes 구성요소를 추측하고 싶으신가요? kubelet입니다. kubelet의 config 파일을 보면 그 안에 DNS 서버와 도메인의 IP가 보인다. 파드가 올바른 이름 서버로 config되면 이제 다른 파드 및 서비스를 확인할 수 있습니다. web service 또는 web service.default 또는 web service.default.svc 또는 webservice.default.svc.cluster.local를 사용하여 웹 서비스에 액세스할 수 있습니다.
NS lookup 또는 호스트 웹 서비스 명령을 사용하여 웹 서비스를 수동으로 조회하려고 하면 웹 서비스의 정규화된 도메인 이름(web-service.default.svc.cluster.local)이 반환됩니다. 하지만 당신은 그것을 요구하지 않았습니다. 당신은 방금 웹 서비스를 말했습니다다. 그렇다면 전체 이름은 어떻게 찾았을까요?
resolv.conf 파일에도 default.service.cluster.local, svc.cluster.local 및 cluster.local로 설정된 검색 항목이 있습니다. 이렇게 하면 이름, 웹 서비스 또는 웹 service.default 또는 웹 service.default.svc를 사용하여 서비스를 찾을 수 있습니다. 그러나 서비스에 대한 검색 항목만 있으므로 동일한 방식으로 포드에 연결할 수 없습니다. 이를 위해서는 포드의 전체 FQDN을 지정해야 합니다.
테스트 문제 기록
Identify the DNS solution implemented in this cluster.
이 클러스터에 구현된 DNS 솔루션
k get pods -n kube-system
What is the name of the service created for accessing CoreDNS?
CoreDNS에 액세스하기 위해 생성된 서비스 이름
k get svc -n kube-system
What is the IP of the CoreDNS server that should be configured on PODs to resolve services?
서비스를 해결하기 위해 POD에 구성해야 하는 CoreDNS 서버의 IP
Where is the configuration file located for configuring the CoreDNS service?
CoreDNS 서비스를 구성하기 위한 구성 파일은 어디에 있습니까?
k describe -n kube-system deployments.apps coredns
How is the Corefile passed into the CoreDNS POD?
Corefile은 CoreDNS POD에 어떻게 전달되나요?
Configured as a ConfigMap object
What is the root domain/zone configured for this kubernetes cluster?
이 kubernetes 클러스터에 대해 구성된 루트 도메인/영역은 무엇입니까?
kubectl describe configmap coredns -n kube-system
테스트 통과 완료
