반응형

목차

  • 서비스 검색
    1. 환경변수를 통한 서비스 검색
    2. DNS를 통한 서비스 검색
    3. FQDN을 통한 서비스 연결
    4. 파드의 컨테이너 내에서 셸 실행

서비스 검색

서비스를 만들면 파드에 액세스할 수 있는 안정적인 IP 주소와 포트가 생깁니다. 이 주소는 서비스각 유지되는 동안 변경되지 않습니다. 이 서비스의 파드는 생성되기도 하고 사라지기도 하고 파드 IP가 변경되거나 파드 수는 늘어나거나 줄어들 수 있지만, 항상 서비스의 IP주소로 액세스할 수 있어야 합니다.

 

그러나 클라이언트 파드는 서비스의 IP와 포트를 어떻게 알 수 있을까요? 다행히 쿠버네티스는 클라이언트 파드가 서비스의 IP와 포트를 검색할 수 있는 방법을 제공합니다. 이번 포스팅에서는 이 방법들에 대해 다뤄보도록 하겠습니다.

 

  1. 환경변수를 통한 서비스 검색

    파드가 시작되면 쿠버네티스는 해당 시점에 존재하는 각 서비스를 가리키는 환경변수 세트를 초기화합니다. 클라이언트 파드를 생성하기 전에 서비스를 생성하면 해당 파드의 프로세스는 환경변수를 검사해 서비스의 IP 주소와 포트를 얻을 수 있습니다.

    현재 실행 중인 파드 중 하나의 환경을 검사해 이러한 환경변수가 어떻게 보이는지 살펴봅시다. 파드를 만든 후에 서비스를 만들면 서비스에 대한 환경변수를 설정할 수 없습니다. 이것을 먼저 해결하는 것이 관건입니다.

    서비스에 대한 환경변수를 보려면 먼저 모든 파드를 삭제하고 레플리케이션컨트롤러에서 새로 파드를 만들어야 합니다. 다음과 같이 이름을 지정하지 않고 모든 파드를 삭제할 수 있습니다.

    kubectl delete pods --all

    이제 새 파드를 조회하고 파드를 kubectl exec 명령어의 대상으로 선택할 수 있습니다. 대상 파드를 선택하면 다음 예제와 같이 컨테이너 내부에서 env 명령어를 샐행해 환경변수를 조회할 수 있습니다.

    kubectl exec <파드이름> env

  2. DNS를 통한 서비스 검색

    kube-system 네임스페이스에 파드를 조회하면, 그 중에는 kube-dns라고 있습니다. kube-system 네임스페이스에는 동일한 이름의 해당 서비스가 있습니다.

    이름에서 알 수 있듯이 이 파드는 DNS 서버를 실행하며 클러스터에서 실행중인 다른 모든 파드는 자동으로 이를 사용하도록 구성됩니다. 쿠버네티스는 각 컨테이너의 /etc/resolv.conf 파일을 수정해 이를 수행합니다. 파드에서 실행 중인 프로세스에서 수행된 모든 DNS 쿼리는 시스템에서 싱행 중인 모든 서비스를 알고 있는 쿠버네티스의 자체 DNS 서버로 처리됩니다.

    이 때 파드가 내부 DNS를 사용할지 여부는  각 파드 스펙의 dnsPolicy 속성으로 구성할 수 있습니다. 각 서비스는 내부 DNS 서버에서 DNS 항목을 가져오고 서비스 이름을 알고 있는 클라이언트 파드는 환경변수 대신 FQDN으로 액세스할 수 있습니다.

    Kubernetes에서는 각 서비스에 대한 클러스터 내 DNS(Domain Name System)가 자동으로 구성됩니다. 이 DNS는 각 서비스의 FQDN을 노출시킵니다. 따라서 FQDN을 사용하여 각 서비스에 접근할 수 있습니다. 다음으로 FQDN에 대해 자세히 알아봅겠습니다.

  3. FQDN을 통한 서비스 연결

    FQDN은 일반적으로 "<service-name>.<namespace>.svc.cluster.local" 형식으로 구성됩니다. 예를 들어, "my-service"라는 이름의 서비스가 "my-namespace" 네임스페이스에 있다면 FQDN은 "my-service.my-namespace.svc.cluster.local"이 됩니다.

    Kubernetes에서 FQDN을 사용하면 서비스 간 통신이 간단해지며, 클러스터 내에서 애플리케이션을 배포하고 확장하는 것이 쉬워집니다. FQDN을 사용하여 클러스터 내에서 서비스를 참조할 수 있으므로, 서비스의 IP 주소나 포트 번호를 변경해도 클라이언트 측에서 변경할 필요가 없습니다.

    FQDN(Fully Qualified Domain Name)은 각 서비스에 대한 DNS 이름입니다. FQDN은 서비스의 이름과 네임스페이스(namespace)를 결합하여 생성됩니다. 프론트엔트-백엔드 예제를 다시 보면 프론트엔드 파드는 다음 FQDN으로 백엔드 데이터베이스 서비스에 연결할 수 있습니다.

    backend-database.default.svc.clister.local

    backend-database는 서비스 이름이고 default는 서비스가 정의된 네임스페이스를 나타내며 svc.cluster.local은 모든 클러스터의 로컬 서비스 이름에 사용되는 클러스터의 도메인 접미사입니다.

    서비스에 연결하는 것은 훨씬 간단합니다. 프론트엔드 파드가 데이터베이스 파드와 동일한 네임스페이스에 있는 경우 svc.cluster.local 접미사와 네임스페이스는 생략할 수 있습니다. 따라서 서비스를 단순히 backend-database라고 할 수 있습니다.

    이제 IP 대신 FQDN으로 kubia 서비스에 액세스할 수 있습니다. 이 동작은 기존 파드 내에서 수행해야 합니다. 이미 kubectl exec를 사용해 파드의 컨테이너에서 명령어를 실행하는 방법은 이미 다루었으니, 이번에는 curl 명령어를 직접 실행하는 대신 bash 셸을 실행해 컨테이너에서 여러 명령어를 실행할 수 있습니다. 이는 docker exec -it bash 명령어로 도커로 실행한 컨테이너에 들어갔던 것과 비슷합니다.

  4. 파드의 컨테이너 내에서 셸 실행

    kubecctl exec 명령어를 사용해 파드의 컨테이너 내에서 bash(혹은 다른 셸)를 실행할 수 있습니다. 이렇게 하면 실행하려는 모든 명령어를 kubectl exec로 수행할 필요 없이 원하는 만큼 컨테이너를 자유롭게 탐색할 수 있습니다. 하지만 이 작업을 수행하기 위해서는 컨테이너 이미지에서 셸 바이너리 실행파일이 사용 가능해야 합니다.

    셸을 올바르게 사용하려면 -it  옵션을 kubectl exec에 넣어야 합니다.

    kubectl exec -it <컨테이너 명> bash

    해당 명령어를 입력하면 컨테이너 안으로 들어갈 수 있습니다. 이제 curl 명령어를 이용해 다음 방법으로 kubia 서비스에 액세스할 수 있습니다. 컨테이너에 들어와 있다는 가정하에 다음 명령어를 통해 다음 명령어를 사용하면 상태가 출력될 것입니다.

    1) curl http://kubia.default.svc.cluster.local 
    2) curl http://kubia.default
    3) curl http://kubia

    요청 URL에서 호스트 이름으로 서비스 이름을 사용해 서비스에 액세스할 수 있습니다. 각 파드 컨테이너 내부의 DNS resolver가 구성돼 있기 때문에 네임스페이스와 ssvc.cluster.local 접미사를 생략할 수 있습니다. 컨테이너에서 /etc/resolv.conf 파일을 vi등을 이용해 열어 보면 원리를 이해할 수 있을 것입니다.

반응형