728x90

서비스의 필요성

pod는 수요에 따라 확장 또는 축소해야 할 수 있고, 애플리케이션 충돌이나 노드 장애가 발생할 경우 다시 생성되기 때문에 매우 동적임

이러한 이벤트로 인해 pod의 IP 주소가 변경되면 네트워킹이 어려워질 수 있음

쿠버네티스는 Service를 사용하여 이 문제를 해결함

  1. 서비스와 연관된 백엔드 Pod를 연결하기 위해 앞단에 정적 가상 IP 주소를 할당
  2. 서비스는 pod의 ip주소를 추적
  3. 서비스는 서비스IP로 전송된 모든 트래픽을 뒷단 pod 세트로 부하 분산
  4. Pod IP 주소가 변경되더라도 클라이언트는 서비스 자체의 정적인 가상 IP 주소로만 직접 연결하기 때문에 Pod에 연결하는 데 아무런 문제가 없음

서비스의 구성 요소

  • Service 객체
    • Service는 Kubernetes 리소스로, API 서버에 정의되어 있음
    • spec.selector 필드를 사용하여 어떤 Pod가 이 서비스에 포함될지를 정의함
    • 예를 들어, app: myapp 라벨을 가진 모든 Pod가 이 서비스의 엔드포인트가 됨
  • Endpoints 객체
    • Service와 연결된 Pod의 IP 주소와 포트 정보를 포함하는 객체
    • Kubernetes 컨트롤러가 자동으로 생성하며, Service의 selector와 일치하는 Pod를 추적함
  • kube-proxy
    • 각 Kubernetes 노드에서 실행되며, Service에 대한 네트워크 트래픽을 적절한 Pod로 라우팅함
    • iptables, IPVS, 또는 유저스페이스 프록시 모드를 사용하여 트래픽을 관리함
      • iptables
        • 이 모드에서 kube-proxy는 API 서버의 변경 사항을 감시함
        • 각 새 서비스에 대해 iptables 규칙을 설치하여 서비스의 clusterIP 및 포트로의 트래픽을 캡처한 다음, 서비스의 백엔드 Pod로 트래픽을 리디렉션
        • Pod는 무작위로 선택됩니다. 이 모드는 안정적이며 Linux Netfilter가 사용자 공간과 커널 공간 사이를 전환할 필요 없이 트래픽을 처리하기 때문에 시스템 오버헤드가 낮음
      • IPVS
        • IPVS는 Netfilter 위에 구축되었으며 전송 계층 부하 분산을 구현함
        • IPVS는 Netfilter 후크 함수를 사용하여 해시 테이블을 기본 데이터 구조로 사용하고 커널 공간에서 작동함
        • IPVS 모드의 kube-proxy는 iptables 모드의 kube-proxy보다 낮은 지연 시간, 높은 처리량 및 더 나은 성능으로 트래픽을 리디렉션함
  • DNS
    • 클러스터 내에서 실행 중인 CoreDNS 또는 kube-dns는 서비스 디스커버리를 위해 Service의 DNS 이름을 관리함
    • 예를 들어, my-service.default.svc.cluster.local 같은 DNS 이름을 사용하여 서비스에 접근할 수 있음

서비스 동작 원리

  1. Service 정의
    • 사용자가 Service 객체를 생성하면 API 서버에 저장됨
    • Service 정의 예시
    • apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: myapp ports: - protocol: TCP port: 80 targetPort: 9376
  2. Pod와 Endpoints 연계
    • selector 필드에 정의된 라벨을 기준으로, 컨트롤러가 해당 라벨을 가진 모든 Pod를 찾아 Endpoints 객체를 생성함
    • Endpoints 객체는 서비스와 관련된 Pod의 IP 주소와 포트를 포함함
  3. kube-proxy 설정
    • 각 노드에서 실행 중인 kube-proxy는 Service와 Endpoints 정보를 주기적으로 API 서버에서 가져와 로컬 iptables 또는 IPVS 규칙을 설정함
  4. 트래픽 라우팅
    • 클러스터 내의 다른 Pod나 외부 클라이언트가 서비스의 클러스터 IP 주소 또는 DNS 이름을 사용하여 접근할 때, 트래픽이 kube-proxy를 통해 라우팅됨
    • kube-proxy는 로드 밸런싱 알고리즘을 사용하여 트래픽을 Endpoints 리스트에 있는 Pod로 분배함
  5. DNS를 통한 서비스 디스커버리
    • CoreDNS 또는 kube-dns가 클러스터 내에서 서비스 이름을 IP 주소로 변환함
    • 예를 들어, my-service.default.svc.cluster.local로 DNS 요청을 하면 서비스의 클러스터 IP 주소를 반환함
728x90

+ Recent posts