Kubernetes의 ClusterIP, NodePort 및 LoadBalancer 서비스 유형의 차이점은 무엇입니까?


230

1-나는 문서를 읽고 있는데 나는 문구와 약간 혼동된다. 그것은 말한다 :

ClusterIP : 서비스를 클러스터 내부 IP에 노출합니다. 이 값을 선택하면 클러스터 내에서만 서비스에 도달 할 수 있습니다. 이것이 기본 서비스 유형입니다

NodePort : 각 노드의 IP 서비스를 고정 포트 (NodePort)에 노출합니다. NodePort 서비스가 라우팅 할 ClusterIP 서비스가 자동으로 작성됩니다. 을 요청하여 클러스터 외부에서 NodePort 서비스에 접속할 수 있습니다 <NodeIP>:<NodePort>.

LoadBalancer : 클라우드 공급자의로드 밸런서를 사용하여 서비스를 외부에 노출합니다. 외부로드 밸런서가 라우팅 할 NodePort 및 ClusterIP 서비스가 자동으로 생성됩니다.

NodePort 서비스 유형은 여전히 ClusterIP외부 클라이언트에 열려있는 다른 포트에서만 사용 합니까? 따라서이 경우 <NodeIP>:<NodePort>와 동일 <ClusterIP>:<NodePort>합니까?

또는 NodeIP실제로 실행할 때 IP가 발견 kubectl get nodes되고 ClusterIP 서비스 유형에 사용 된 가상 IP가 아닌가?

2-아래 링크의 다이어그램에서도 :

http://kubernetes.io/images/docs/services-iptables-overview.svg

Client안에 왜 특별한 이유 가 Node있습니까? ClusterClusterIP 서비스 유형의 경우 내부에 있어야한다고 가정했습니다 .

같은 그림이 NodePort을 위해 그려진 경우, 완전히 외부 모두 클라이언트를 그릴 유효 할 것입니다 Node및 Cluster또는 나는 완전히 지점을 놓친 거지?

답변:


217

ClusterIP는 다음을 노출합니다.

  • spec.clusterIp:spec.ports[*].port

클러스터 내부에서만이 서비스에 액세스 할 수 있습니다. spec.clusterIp포트 에서 액세스 할 수 있습니다 . a spec.ports[*].targetPort로 설정하면 포트에서 대상 포트로 라우팅됩니다. 호출 할 때 얻는 CLUSTER-IP kubectl get services는 내부적으로 클러스터 내에서이 서비스에 할당 된 IP입니다.

NodePort는 다음을 노출합니다.

  • <NodeIP>:spec.ports[*].nodePort
  • spec.clusterIp:spec.ports[*].port

노드의 외부 IP에서 nodePort의이 서비스에 액세스하면 요청이 (으)로 라우팅되고 설정된 경우 요청 spec.clusterIp:spec.ports[*].port이 (으)로 라우팅 spec.ports[*].targetPort됩니다. 이 서비스는 ClusterIP와 같은 방식으로 액세스 할 수도 있습니다.

NodeIP는 노드의 외부 IP 주소입니다. 에서 서비스에 액세스 할 수 없습니다 <ClusterIP>:spec.ports[*].nodePort.

LoadBalancer는 다음을 노출합니다.

  • spec.loadBalancerIp:spec.ports[*].port
  • <NodeIP>:spec.ports[*].nodePort
  • spec.clusterIp:spec.ports[*].port

로드 밸런서의 IP 주소에서이 서비스에 액세스 할 수 있습니다.이 주소는 요청을 nodePort로 라우트 한 다음 요청을 clusterIP 포트로 라우트합니다. NodePort 또는 ClusterIP 서비스와 마찬가지로이 서비스에 액세스 할 수 있습니다.


3
externalIPs여기서 방정식 을 어떻게 바꾸는 지에 대해 언급 해 주시겠습니까? 특히, externalIPs배열을 ClusterIP-type 서비스 에 할당 할 수 있는데 외부 IP에서도 서비스에 액세스 할 수 있습니까? NodePort를 통해 언제 이것을 선택 하시겠습니까?
— Bosh

이 질문에는 externalIPs가 언급되어 있지 않습니다.이 질문을 새로운 질문으로 게시하면 가장 잘 제공 될 것입니다.
— kellanburket

39
이 게시물은 실제로 공식 Kubernetes 문서 자체보다 이러한 차이점을 명확하게 설명하는 것이 더 유용합니다.
— adrpino

@kellanburket, 어떻게 작동합니까 : spec.clusterIp. service.yaml에서 ClusterIP를 명시 적으로 언급 할 수 있습니다. 비슷하게spec.loadBalancerIp
— samshers

당신은 당신의 대답으로 내 하루를 만들었습니다. 대단히 감사합니다! (2020 년에 여전히 네트워킹 문서는 약간 애매 모호하다.)
— user430191

103

더 간단한 수준에서 3의 차이점을 찾고있는 사람을 명확히합니다. 최소한의 ClusterIp (k8s 클러스터 내) 또는 NodePort (k8s 클러스터 외부의 클러스터 내) 또는 LoadBalancer (외부 세계 또는 LB에서 정의한 모든 것)로 더 큰 노출로 서비스를 노출 할 수 있습니다.

ClusterIp 노출 <NodePort 노출 <LoadBalancer 노출

  • ClusterIp k8s 클러스터 를
    통한 서비스 노출ip/name:port
  • 내부 네트워크 VM을
    통한 NodePort Expose 서비스 ( k8 외부)ip/name:port
  • LoadBalancer 외부 세계 또는 LB에서 정의한 모든 것을
    통해 서비스를 노출 하십시오.

53

ClusterIP : 클러스터의 포드 / 서비스를 통해 서비스에 액세스 할 수 있습니다
. 기본 네임 스페이스 : clusterIP에서 myservice라는 서비스를 만들면 서비스에 대해 예측 가능한 다음 정적 DNS 주소가 생성됩니다.

myservice.default.svc.cluster.local (또는 myservice.default 또는 기본 네임 스페이스의 포드 만 "myservice"가 작동 함)

그리고 해당 DNS 이름은 클러스터 내부의 포드 및 서비스로만 확인할 수 있습니다.

NodePort : K8 호스트 노드 (및 클러스터의 포드 / 서비스)를 핑 (ping) 할 수있는 동일한 LAN / 클라이언트의 클라이언트가 서비스에 접근 할 수 있습니다 (보안을 위해 k8s 호스트 노드는 개인 서브넷에 있어야합니다. 이 서비스에 연결할 수 없습니다.)
mynamespace 네임 스페이스에서 mynodeportservice라는 서비스를 다음과 같은 유형으로 만드는 경우 : 3 노드 Kubernetes 클러스터의 NodePort. 그런 다음 서비스 유형 : ClusterIP가 생성되고 예측 가능한 다음 고정 DNS 주소로 클러스터 내부의 클라이언트가 도달 할 수 있습니다.

mynodeportservice.mynamespace.svc.cluster.local (또는 mynodeportservice.mynamespace)

mynodeportservice가 30000-32767 범위의 노드 포트에서 수신하는 각 포트에 대해 무작위로 선택됩니다. 따라서 클러스터 외부에있는 외부 클라이언트는 클러스터 내부에있는 해당 ClusterIP 서비스에 충돌 할 수 있습니다. 3 개의 K8 호스트 노드에 IP 10.10.10.1, 10.10.10.2, 10.10.10.3이 있고 Kubernetes 서비스가 포트 80에서 수신 대기하고 임의로 선택된 노드 포트가 31852

라고 가정합니다. 클러스터 외부에 존재하는 클라이언트는 방문 할 수 있습니다 10.10.10.1:31852, 10.10.10.2:31852 또는 10.10.10.3:31852 (모든 Kubernetes 호스트 노드가 NodePort를 수신하므로) Kubeproxy는 요청을 mynodeportservice의 포트 80으로 전달합니다.

LoadBalancer : 인터넷에 연결된 모든 사람이 서비스에 액세스 할 수 있습니다 * (공통 아키텍처는 L4 LB를 인터넷에 DMZ에 넣거나 사설 및 공용 IP 및 k8s 호스트 노드를 사설 서브넷에 제공하여 인터넷에서 공개적으로 액세스 할 수 있음)
( 참고 : 베어 메탈 Kubernetes와 같이 Kubernetes 구현에서 100 % 작동하지 않는 유일한 서비스 유형입니다. Kubernetes에 클라우드 공급자 통합이있을 때 작동합니다.)

mylbservice를 작성하면 L4 LB VM이 생성됩니다 (클러스터 IP 서비스 및 NodePort 서비스도 암시 적으로 생성됨). 이번에는 NodePort가 30222입니다. L4 LB의 공용 IP는 1.2.3.4이며 개인 IP 주소가있는 3 개의 K8 호스트 노드로 트래픽을로드 밸런싱하고 전달합니다. (10.10.10.1:30222, 10.10.10.2:30222, 10.10.10.3:30222) 그런 다음 Kube 프록시는이를 클러스터 내에 존재하는 ClusterIP 유형의 서비스로 전달합니다.


또한 NodePort 서비스 유형이 여전히 ClusterIP를 사용합니까? 예 *
아니면 kubectl get 노드를 실행할 때 NodeIP가 실제로 IP입니까? 또한 예 *

기본 사항 사이에 평행선을 그릴 수 있습니다.
컨테이너가 포드 안에 있습니다. 포드는 복제 세트 안에 있습니다. 복제 세트가 배포 내부에 있습니다.
마찬가지로
, ClusterIP 서비스는 NodePort 서비스의 일부입니다. NodePort 서비스는로드 밸런서 서비스의 일부입니다.


이 다이어그램에서 클라이언트는 클러스터 내부의 포드입니다.


후속 질문을 바탕으로 트래픽이 클러스터에 어떻게 입력되었는지 알고 싶다는 인상을 받았습니다. 당신이 관심이 있다면 나는 그것에 대한 Q & A를 자유로 웠습니다. stackoverflow.com/questions/52241501/…
— neokyle

1
안녕하세요, 정말 좋은 설명입니다. LoadBalancer에 대해 궁금합니다. LoadBalancer는 모든 트래픽을 NodeIP : NodePort (라운드 로빈에서 다음 노드)로 전달하며 해당 노드에서 호출이 어떻게 진행됩니까? 노드 포트는 이것이 서비스 호출이고 kube-proxy를 통해 서비스의 가상 IP로 분배해야한다는 것을 어떻게 알 수 있습니까? kube-proxy가 간단한 포트 포워드를 수행합니까?
— ItFreak

kube-proxy는 3 가지 주요 역할을 수행합니다. 1. 노드의 iptables 등을 원하는 서비스 상태와 일치시켜 서비스를 존재 / 작업으로 만듭니다. 2. 노드 포트를 서비스로 포드에 매핑하는 책임이 있습니다. 노드 포트는 하나의 노드에 들어갈 수 있고, 서비스 정의는 모든 노드의 iptables에 있으며 모든 노드에 존재하며, 포드는 일반적으로 가상화 된 오버레이 네트워크에 있으며, 노드는 라우터로 두 배가됩니다. 다른 노드에있는 포드로 라우팅됩니다.
— neokyle

쿠 버네 티스는 모듈 식 조각으로 만들어 졌기 때문에 리눅스가 여러 가지 테마로 약간 다르게 작동하는 풍미 / 디스크가있는 것처럼 각 k8 배포판은 약간 다릅니다. cilium cni 예제는 kube-proxy를 완전히 대체하려고합니다. 즉, 장면 뒤에서 작동하는 방식이 움직이는 목표이므로 실제로 프로젝트에 기여하지 않고 버그를 수정하려고 시도하지 않는 한 이해할 가치가 없습니다.
— neokyle

연락 할 수있는 방법이 있습니까? k8s의 보안에 관한 학사 논문을 작성하고 있으며 프록시의 인턴 기능에 대해 배우고 싶습니다. 예를 들어 IP 주소를 노드와 포드에 어떻게 배포하고 서비스가 가상 IP를 얻는 방법
— ItFreak

45

로컬 컴퓨터에서 Ubuntu VM을 생성했다고 가정하겠습니다. IP 주소는 192.168.1.104 입니다.

VM에 로그인하여 Kubernetes를 설치했습니다. 그런 다음 nginx 이미지가 실행되는 포드를 만들었습니다.

1- VM 내에서이 nginx 포드에 액세스 하려면 해당 포드에 바인딩 된 ClusterIP 를 작성합니다 . 예를 들면 다음과 같습니다.

$ kubectl expose deployment nginxapp --name=nginxclusterip --port=80 --target-port=8080

그런 다음 브라우저에서 다음과 같이 포트 80으로 nginxclusterip의 ip 주소를 입력 할 수 있습니다.

http://10.152.183.2:80

2- 호스트 시스템에서이 nginx 포드에 액세스하려면 NodePort를 사용 하여 배포를 노출해야합니다 . 예를 들면 다음과 같습니다.

$ kubectl expose deployment nginxapp --name=nginxnodeport --port=80 --target-port=8080 --type=NodePort

이제 호스트 컴퓨터에서 다음과 같이 nginx에 액세스 할 수 있습니다.

http://192.168.1.104:31865/

내 대시 보드에서 다음과 같이 나타납니다.

여기에 이미지 설명을 입력하십시오

아래는 기본 관계를 보여주는 다이어그램입니다.

여기에 이미지 설명을 입력하십시오


31865는 어디에서 왔습니까? 생성 되었습니까?
— HoaPhan

1
@HoaPhan 30000-32767 범위에서 포트를 명시 적으로 지정하거나이 범위에서 Kubernetes가 임의로 선택하도록 할 수 있습니다.
— Mohammad Torkashvand

20

이 질문에 이미 답이 있더라도 더 나은 이해를 위해 다른 질문을 제공 할 것입니다.

1. ClusterIP Kubernetes의 기본 서비스 유형이며이 유형은 클러스터 내부에 서비스를 제공합니다. 이를 사용하면 클러스터의 다른 응용 프로그램이 Kubernetes 프록시를 통해 서비스에 액세스 할 수 있습니다.

이 유형의 서비스를 프로덕션 서비스 노출에 사용해서는 안된다는 점을 언급해야합니다. 그러나 사용할 수 있습니다

  • 서비스 간의 통합 디버깅;
  • 비업무 관련 데이터를 노출하는 내부 서비스에 액세스 (모니터링 대시 보드).

요청이 진행되는 방식은 트래픽-> K8s 프록시-> K8s 서비스 (ClusterIP)-> 포드 이며 다음 그림에 표시됩니다.

여기에 이미지 설명을 입력하십시오

2. NodePort 는 외부 트래픽을 수락하고이를 kubernetes 서비스로 전달하는 가장 기본적인 방법입니다. 이름에서 알 수 있듯이 NodePort 서비스 유형은 특정 포트로 전송 된 트래픽이 서비스로 전달 될 수 있도록 모든 가상 머신, 즉 Kubernetes 노드에서 특정 포트를 엽니 다.

NodePort 서비스 유형에는 몇 가지 단점이 있습니다.

  • 포트 당 하나의 서비스 만 있으면됩니다.
  • 가상 머신의 IP가 변경되면 클러스터에서 일부 변경을 수행해야합니다.
  • 3000-32767 사이의 포트만 사용할 수 있습니다.

요청 방식은 다음과 같습니다 : 트래픽-> 가상 머신에 노출 된 포트-> K8s 서비스 (NodePort)-> 포드 . 다음 그림에 표시됩니다.

여기에 이미지 설명을 입력하십시오

3.로드 밸런서 는 인터넷에 서비스를 노출시키는 표준 방법입니다. 서비스와 특정 포트의 모든 트래픽을 서비스에 직접 노출시키기를 원하는 경우,이를 수행 할 수 있습니다. 또한 LoadBalancer 서비스 유형에는 필터링 또는 라우팅이 포함되지 않습니다. 또한 TCP, UDP, HTTP gRPC 트래픽을 전송할 수 있습니다.

단점 : LoadBalancer를 통해 노출 된 각 서비스에는 고유 한 IP 주소가 있으며 모든 서비스는 단일 LoadBalancer를 통해 노출되어 비용이 많이들 수 있습니다.

요청의 경로는 traffic-> LoadBalancer-> K8s Service-> pods 이며 다음 그림과 같이 표시됩니다.

여기에 이미지 설명을 입력하십시오


7
  1. clusterIP : 클러스터 내에서 액세스 가능한 IP (d 클러스터 내의 노드 간)
nodeA : pod1 => clusterIP1, pod2 => clusterIP2
nodeB : pod3 => clusterIP3.

pod3은 clusterIP 네트워크를 통해 pod1과 통신 할 수 있습니다.

  1. nodeport : nodeIP : nodeport를 통해 클러스터 외부에서 포드에 액세스 할 수 있도록 clusterIP 네트워크보다 위에 clusterIP를 작성 / 유지합니다.
nodeA => nodeIPA : nodeportX
nodeB => nodeIPB : nodeportX

nodeIPA : nodeportX 또는 nodeIPB : nodeportX를 통해 pod1의 서비스에 액세스 할 수 있습니다. kube-proxy (각 노드에 설치되어 있음)는 요청을 수신하고 clusterIP 네트워크를 사용하여 노드에 요청을 전달 (iptables term)하기 때문에 어느 쪽이든 작동합니다.

  1. 로드 밸런서

기본적으로 LB를 앞에두면 인바운드 트래픽이 nodeIPA : nodeportX 및 nodeIPB : nodeportX에 분산 된 다음 위의 프로세스 플로우 번호 2로 계속됩니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.