수신 및로드 밸런서
답변:
로드 밸런서 : kubernetes LoadBalancer 서비스는 kubernetes 클러스터에 없지만 다른 곳에 존재하는 외부로드 밸런서를 가리키는 서비스입니다. 포드를 외부에서 라우팅 할 수 있다고 가정하면 포드와 함께 작동 할 수 있습니다. Google과 AWS는 기본적으로이 기능을 제공합니다. Amazon 측면에서, 이는 AWS에서 실행될 때 ELB 및 kubernetes와 직접 매핑되므로 배포 된 각 LoadBalancer 서비스에 대해 ELB 인스턴스를 자동으로 프로비저닝하고 구성 할 수 있습니다.
수신 : 수신은 실제로 수신 대기중인 컨트롤러에 전달할 규칙 세트입니다. 많은 수신 규칙을 배포 할 수 있지만이를 처리 할 수있는 컨트롤러가 없으면 아무 일도 일어나지 않습니다. LoadBalancer 서비스는 수신 규칙을 수신하도록 구성 할 수 있습니다.
클러스터 외부에 라우팅 가능한 외부 IP가 있지만 클러스터 내에 존재하는 포드를 가리키는 NodePort 서비스를 만들 수도 있습니다 . 수신 컨트롤러 일 수 있습니다.
수신 컨트롤러는 수신 규칙을 해석하도록 구성된 포드입니다. kubernetes가 지원하는 가장 널리 사용되는 수신 컨트롤러 중 하나는 nginx입니다. Amazon의 관점에서 ALB 는 수신 컨트롤러 로 사용될 수 있습니다 .
예를 들어, 이 nginx 컨트롤러는 사용자가 정의한 수신 규칙을 수집하고이를 포드에서로드하고 시작하는 nginx.conf 파일로 변환 할 수 있습니다.
예를 들어 다음과 같이 수신을 정의했다고 가정 해 봅시다.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
ingress.kubernetes.io/rewrite-target: /
name: web-ingress
spec:
rules:
- host: kubernetes.foo.bar
http:
paths:
- backend:
serviceName: appsvc
servicePort: 80
path: /app
그런 다음 nginx 컨트롤러 포드를 검사하면에 정의 된 다음 규칙이 표시됩니다 /etc/nginx.conf.
server {
server_name kubernetes.foo.bar;
listen 80;
listen [::]:80;
set $proxy_upstream_name "-";
location ~* ^/web2\/?(?<baseuri>.*) {
set $proxy_upstream_name "apps-web2svc-8080";
port_in_redirect off;
client_max_body_size "1m";
proxy_set_header Host $best_http_host;
# Pass the extracted client certificate to the backend
# Allow websocket connections
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header X-Real-IP $the_real_ip;
proxy_set_header X-Forwarded-For $the_x_forwarded_for;
proxy_set_header X-Forwarded-Host $best_http_host;
proxy_set_header X-Forwarded-Port $pass_port;
proxy_set_header X-Forwarded-Proto $pass_access_scheme;
proxy_set_header X-Original-URI $request_uri;
proxy_set_header X-Scheme $pass_access_scheme;
# mitigate HTTPoxy Vulnerability
# https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
proxy_set_header Proxy "";
# Custom headers
proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
proxy_redirect off;
proxy_buffering off;
proxy_buffer_size "4k";
proxy_buffers 4 "4k";
proxy_http_version 1.1;
proxy_cookie_domain off;
proxy_cookie_path off;
rewrite /app/(.*) /$1 break;
rewrite /app / break;
proxy_pass http://apps-appsvc-8080;
}
Nginx는 방금 클러스터 http://kubernetes.foo.bar/app의 서비스를 가리 키도록 라우팅하는 규칙을 만들었습니다 appsvc.
다음은 nginx 수신 컨트롤러로 kubernetes 클러스터를 구현하는 방법 의 예 입니다. 도움이 되었기를 바랍니다!
NodePort, LoadBalancer 및 Ingress의 차이점을 설명하는 이 흥미로운 기사 를 찾았습니다 .
기사에있는 내용에서 :
로드 밸런서 :
LoadBalancer 서비스는 인터넷에 서비스를 노출시키는 표준 방법입니다. GKE에서는 네트워크로드 밸런서가 가동되어 모든 트래픽을 서비스로 전달하는 단일 IP 주소를 제공합니다.
서비스를 직접 노출하려면 이것이 기본 방법입니다. 지정한 포트의 모든 트래픽이 서비스로 전달됩니다. 필터링, 라우팅 등이 없습니다. 즉, HTTP, TCP, UDP, 웹 소켓, gRPC 등과 같은 거의 모든 종류의 트래픽을 전송할 수 있습니다.
가장 큰 단점은 LoadBalancer로 노출하는 각 서비스는 고유 한 IP 주소를 얻게되며 노출 된 서비스 당 LoadBalancer를 지불해야하므로 비용이 많이들 수 있습니다.
입구:
수신은 실제로 서비스 유형이 아닙니다. 대신 여러 서비스 앞에 있으며 "스마트 라우터"또는 클러스터의 진입 점 역할을합니다.
Ingress로 다양한 작업을 수행 할 수 있으며 기능이 다른 여러 유형의 Ingress 컨트롤러가 있습니다.
기본 GKE 수신 컨트롤러가 HTTP (S)로드 밸런서를 스핀 업합니다. 이를 통해 백엔드 서비스에 대한 경로 기반 및 하위 도메인 기반 라우팅을 모두 수행 할 수 있습니다. 예를 들어 foo.yourdomain.com의 모든 것을 foo 서비스로 보내고 yourdomain.com/bar/ 경로 아래의 모든 것을 bar 서비스로 보낼 수 있습니다.
Ingress는 아마도 가장 강력한 서비스 노출 방법이지만 가장 복잡한 방법 일 수도 있습니다. Google Cloud Load Balancer, Nginx, Contour, Istio 등 다양한 유형의 Ingress 컨트롤러가 있습니다. cert-manager와 같은 Ingress 컨트롤러 용 플러그인이있어 서비스에 대한 SSL 인증서를 자동으로 프로비저닝 할 수 있습니다.
동일한 IP 주소로 여러 서비스를 노출하려는 경우 Ingress가 가장 유용하며 이러한 서비스는 모두 동일한 L7 프로토콜 (일반적으로 HTTP)을 사용합니다. 기본 GCP 통합을 사용하는 경우 하나의로드 밸런서에 대해서만 비용을 지불하며 Ingress가 "스마트"하므로 많은 기능 (SSL, 인증, 라우팅 등)을 즉시 얻을 수 있습니다.
TL : DR
- Ingress는 공용 네트워크 (인터넷)와 Api 구현을 공개적으로 노출하는 Kubernetes 서비스 사이에 있습니다.
- Ingress는로드 균형 조정, SSL 종료 및 이름 기반 가상 호스팅을 제공 할 수 있습니다.
- 수신 기능을 사용하면 단일 도메인 이름에서 여러 API 또는 애플리케이션을 안전하게 노출 할 수 있습니다.
실제 사용 사례로 시작해 보겠습니다. 서비스 구현 패키지 (명확하고 간결한 ASIP)로 여러 Apis를 지원하여 단일 도메인 이름으로 배포 할 수 있습니다. 최첨단 개발자는 각 ASIP에 대해 개별 배포가 필요하므로 개별적으로 업그레이드하거나 확장 할 수있는 마이크로 서비스 아키텍처를 구현했습니다. 물론 이러한 ASIP는 개별 도커 컨테이너에 캡슐화되어 있으며 컨테이너 저장소에서 Kubernetes (K8)가 사용할 수 있습니다.
이것을 Google의 GKE K8에 배포하려고한다고 가정하겠습니다. 지속적인 가용성을 구현하기 위해 각 ASIP 인스턴스 (복제본)는 각 VM에 자체 클라우드 내부 IP 주소가있는 다른 노드 (VM)에 배포됩니다. 각 ASIP 배포는 적절한 이름의 "deployment.yaml"파일로 구성되며, 여기에서 지정된 ASIP K8의 복제본 수를 선언적으로 지정합니다.
다음 단계는 API를 ouside 세계에 노출시키고 요청을 배치 된 ASIP 인스턴스 중 하나에 퍼널 링하는 것입니다. 서로 다른 노드에서 실행되는 동일한 ASIP의 많은 복제본이 있으므로 해당 복제본간에 요청을 분배 할 무언가가 필요합니다. 이 문제를 해결하기 위해 외부에서 노출되고 IP 주소를 통해 액세스 할 수있는 K8s 서비스 (KServ)를 구성하는 "service.yaml"파일을 만들어 적용 할 수 있습니다. 이 KServ는 구성된 ASIP간에 API 요청 분배를 담당합니다. KServ는 ASIP의 노드가 실패하고 재시작 될 때 K8s 마스터에 의해 자동으로 재구성됩니다. 이 경우 내부 IP 주소는 재사용되지 않으며 KServ에 새 ASIP의 배치 위치를 알려야합니다.
그러나 동일한 도메인 이름에 노출 될 다른 Api 서비스 패키지가 있습니다. 새로운 KServ를 돌리면 새로운 외부 IP 주소가 만들어 지므로 동일한 도메인 이름으로 노출 할 수 없습니다. 자, 이것이 Ingress가 들어오는 곳입니다.
인터넷과 외부 세계에 노출되는 모든 KService 사이에 Ingress 앉아 있습니다. Ingress는로드 밸런싱, SSL 종료 및 이름 기반 가상 호스팅을 제공 할 수 있습니다. 후자의 용량은 들어오는 요청을 URL을 분석하여 올바른 서비스로 라우팅 할 수 있습니다. 물론 Ingress는 올바른 KServ에 요청을 보내는 데 필요한 경로와 재 작성을 지정하는 "ingress.yaml"파일로 구성하고 적용해야합니다.
인터넷-> 수신-> K8s 서비스-> 복제본
따라서 올바른 수신, KService 및 ASIP 구성을 통해 동일한 도메인 이름을 사용하여 많은 API를 안전하게 노출 할 수 있습니다.
클러스터의 포드가 외부 트래픽을 수신 할 수 있도록하는 4 가지 방법이 있습니다.
1.) HostNetworking을 사용하는 포드 : true 및 (노드 당 1 개의 포드가 호스트 노드의 포트를 직접 수신하도록 허용합니다.) 호스트 노드가 포트 80/443에서 수신 대기 할 수있는이 경로는로드 밸런서 또는 고급 클라우드로드 밸런서 구성을 사용하지 않고 Kubernetes 서비스를 우회하여 SNAT를 피하거나 externalTrafficPolicy의 유사한 효과를 달성하는 데 유용 할 수 있습니다. 이 AWS에 같이 지원되지 않는 곳.)
2) NodePort 서비스
3) NodePort 서비스에 기반로드 밸런서 서비스 ()
4.) 침투 컨트롤러 + 침투가 (개체 위에 구축 어떤)
클러스터에 10 개의 웹 사이트가 호스팅되어 있고 외부 웹 사이트에 모두 노출하려고한다고 가정합니다.
* LoadBalancer 서비스 유형을 사용하는 경우 HA Cloud로드 밸런서 10 개가 생성됩니다 (각 비용)
* Ingress Controller 유형을 사용하는 경우 1 개의 HA Cloud로드 밸런서 (돈 절약)가 생성되며 Ingress를 가리 킵니다. 클러스터에서 컨트롤러가 실행 중입니다.
수신 컨트롤러는 다음과 같습니다.
- 클러스터에서 실행중인 포드를 배포하여 Load Balancer 유형의 서비스를 지원합니다.
- 각 포드는 2 가지 작업을 수행합니다.
- 클러스터 내에서 실행되는 Layer 7로드 밸런서 역할을합니다. (Nginx는 많은 맛이 나옵니다)
- 클러스터의 Ingress 객체를 기반으로 동적으로 자체 구성
(Ingress 객체는 Layer 7로드 밸런서의 선언적 구성 스 니핏으로 간주 될 수 있음)
클러스터 내부의 L7 LB / Ingress 컨트롤러로드 균형 조정 / 역 프록시는 클러스터 내부의 클러스터 IP 서비스로 트래픽을 프록시합니다. TLS 인증서 유형의 Kubernetes Secret 및이를 참조하는 Ingress 객체가있는 경우 HTTPS를 종료 할 수도 있습니다.)
수신 : 수신 객체 + 수신 컨트롤러
수신 객체 :
자체적으로 아무것도하지 않는 것을 제외하고는 서비스 객체와 같습니다. Ingress 객체는 요청 경로, 요청 도메인 및 대상 kubernetes 서비스 등을 지정하여 Layer 7 트래픽을 클러스터로 라우팅하는 방법을 설명합니다.
수신 컨트롤러 :
다음과 같은 서비스 :
1. listens on specific ports (usually 80 and 443) for web traffic
2. Listens for the creation, modification, or deletion of Ingress Objects
3. Creates internal L7 routing rules based on these Ingress Objects
예를 들어 Nginx Ingress Controller는 서비스를 사용하여 포트 80 및 443에서 수신 한 다음 새 Ingress 객체를 읽고이를 새로운 서버 {} 섹션으로 구문 분석하여 nginx.conf에 동적으로 배치 할 수 있습니다.
LoadBalancer : 외부로드 밸런서 공급자 + 서비스 유형
외부로드 밸런서 공급자 :
외부로드 밸런서 제공자는 일반적으로 AWS 및 GKE와 같은 클라우드에서 구성되며 외부로드 밸런서를 생성하여 외부 IP를 할당 할 수있는 방법을 제공합니다. 이 기능은 서비스를 "LoadBalancer"유형으로 지정하여 사용할 수 있습니다.
서비스 종류:
서비스 유형이 LoadBalancer로 설정되면 Kubernetes는 Kubernetes 포드에 대한 항목을 사용하여 외부로드 밸런서를 생성 한 다음 외부 IP를 할당하려고 시도합니다.
Kubernetes 서비스 컨트롤러는 외부로드 밸런서 생성, 상태 확인 (필요한 경우), 방화벽 규칙 (필요한 경우) 생성을 자동화하고 클라우드 공급자가 할당 한 새로 생성 또는 구성된 LoadBalancer의 외부 IP를 검색하여 서비스 객체.
관계 :
Ingress Controller 서비스는 종종 LoadBalancer 유형으로 프로비저닝되므로 http 및 https 요청을 외부 IP를 통해 특정 내부 서비스로 프록시 / 라우팅 할 수 있습니다.
그러나 LoadBalancer가 꼭 필요한 것은 아닙니다. hostNetwork 또는 hostPort를 사용하면 기술적으로 호스트의 포트를 서비스에 바인딩 할 수 있습니다 (호스트 외부 ip : port를 통해 해당 포트를 방문 할 수 있음). 공식적으로 이것은 실제 노드에서 포트를 사용하므로 권장하지 않습니다.
참고 문헌 :
https://kubernetes.io/docs/concepts/configuration/overview/#services
https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/
https://kubernetes.io/docs/concepts/services-networking/ingress/