Kubernetes에서 장기 연결의 로드 밸런싱 및 확장

이 문서는 Kubernetes에서 로드 밸런싱이 작동하는 방식, 장기 연결을 확장할 때 발생하는 상황, HTTP/2, gRPC, RSocket, AMQP 또는 기타 장기 프로토콜을 사용하는 경우 클라이언트 측 밸런싱을 고려해야 하는 이유를 이해하는 데 도움이 됩니다. . 

Kubernetes에서 트래픽이 재분배되는 방법에 대해 조금 설명합니다. 

Kubernetes는 애플리케이션 배포를 위한 두 가지 편리한 추상화, 즉 서비스와 배포를 제공합니다.

배포는 특정 시간에 실행되어야 하는 애플리케이션의 복사본 수와 방법을 설명합니다. 각 애플리케이션은 포드로 배포되고 IP 주소가 할당됩니다.

서비스는 기능 면에서 로드 밸런서와 유사합니다. 여러 포드에 트래픽을 분산하도록 설계되었습니다.

어떻게 생겼는지 보자.

1. 아래 다이어그램에서는 동일한 애플리케이션과 로드 밸런서의 세 가지 인스턴스를 볼 수 있습니다.

   

2. 로드 밸런서는 서비스라고 하며 IP 주소가 할당됩니다. 들어오는 요청은 Pod 중 하나로 리디렉션됩니다.

   

3. 배포 시나리오에 따라 애플리케이션 인스턴스 수가 결정됩니다. 다음 항목에서 직접 확장할 필요는 거의 없습니다.

   

4. 각 포드에는 자체 IP 주소가 할당됩니다.

   

서비스를 IP 주소 모음으로 생각하면 유용합니다. 서비스에 접속할 때마다 목록에서 IP 주소 중 하나가 선택되어 대상 주소로 사용됩니다.

다음과 같습니다.

1. 컬 10.96.45.152 요청이 서비스에 수신됩니다.

   

2. 서비스는 세 개의 Pod 주소 중 하나를 대상으로 선택합니다.

   

3. 트래픽이 특정 포드로 리디렉션됩니다.

   

애플리케이션이 프런트엔드와 백엔드로 구성된 경우 각각에 대한 서비스와 배포가 모두 제공됩니다.

프런트엔드가 백엔드에 요청할 때 백엔드가 제공하는 포드 수를 정확히 알 필요는 없습니다. XNUMX개, XNUMX개 또는 XNUMX개가 있을 수 있습니다.

또한 프런트엔드는 백엔드를 제공하는 포드의 주소에 대해 아무것도 모릅니다.

프런트엔드가 백엔드에 요청할 때 변경되지 않는 백엔드 서비스의 IP 주소를 사용합니다.

여기 보이는 방법.

1. 1 미만에서는 내부 백엔드 구성 요소를 요청합니다. 백엔드에 대해 특정 항목을 선택하는 대신 서비스에 요청합니다.

   

2. 서비스는 백엔드 Pod 중 하나를 대상 주소로 선택합니다.

   

3. 트래픽은 서비스에서 선택한 Pod 1에서 Pod 5로 이동합니다.

   

4. Under 1은 서비스 뒤에 숨겨져 있는 Under 5와 같은 Pod의 수를 정확히 알지 못합니다.

   

하지만 서비스는 요청을 정확히 어떻게 배포합니까? 라운드 로빈 밸런싱을 사용하는 것 같나요? 그것을 알아 봅시다. 

Kubernetes 서비스의 균형 조정

Kubernetes 서비스가 존재하지 않습니다. IP 주소와 포트가 할당된 서비스에는 프로세스가 없습니다.

클러스터의 노드에 로그인하고 netstat -ntlp 명령을 실행하여 이를 확인할 수 있습니다.

서비스에 할당된 IP 주소도 찾을 수 없습니다.

서비스의 IP 주소는 제어 계층, 컨트롤러에 있으며 데이터베이스(etcd)에 기록됩니다. 동일한 주소가 다른 구성요소인 kube-proxy에서 사용됩니다.
Kube-proxy는 모든 서비스에 대한 IP 주소 목록을 수신하고 클러스터의 각 노드에 iptables 규칙 세트를 생성합니다.

이러한 규칙은 다음과 같이 말합니다. "서비스의 IP 주소가 보이면 요청의 대상 주소를 수정하여 포드 중 하나로 보내야 합니다."

서비스 IP 주소는 진입점으로만 사용되며 해당 IP 주소 및 포트를 수신하는 프로세스에서는 제공되지 않습니다.

이것을 살펴보자. 

1. 세 개의 노드로 구성된 클러스터를 생각해 보세요. 각 노드에는 Pod가 있습니다.

   

2. 베이지색으로 칠해진 묶음 포드도 서비스의 일부입니다. 서비스가 프로세스로 존재하지 않기 때문에 회색으로 표시됩니다.

   

3. 첫 번째 Pod는 서비스를 요청하고 연결된 Pod 중 하나로 이동해야 합니다.

   

4. 하지만 서비스도 존재하지 않고, 프로세스도 존재하지 않습니다. 어떻게 작동하나요?

   

5. 요청이 노드를 떠나기 전에 iptables 규칙을 따릅니다.

   

6. iptables 규칙은 서비스가 존재하지 않는다는 것을 알고 해당 IP 주소를 해당 서비스와 연결된 Pod의 IP 주소 중 하나로 바꿉니다.

   

7. 요청은 유효한 IP 주소를 대상 주소로 수신하고 정상적으로 처리됩니다.

   

8. 네트워크 토폴로지에 따라 요청은 결국 Pod에 도달합니다.

   

iptables는 로드 밸런싱을 할 수 있나요?

아니요, iptables는 필터링에 사용되며 균형 조정을 위해 설계되지 않았습니다.

그러나 다음과 같이 작동하는 일련의 규칙을 작성하는 것이 가능합니다. 유사 밸런서.

이것이 바로 Kubernetes에서 구현되는 것입니다.

포드가 XNUMX개 있는 경우 kube-proxy는 다음 규칙을 작성합니다.

1. 확률이 33%인 첫 번째 하위를 선택하고, 그렇지 않으면 다음 규칙으로 이동합니다.
2. 확률이 50%인 두 번째 규칙을 선택하고, 그렇지 않으면 다음 규칙으로 이동합니다.
3. 아래에서 세 번째를 선택합니다.

이 시스템을 사용하면 각 Pod가 33%의 확률로 선택됩니다.

그리고 Pod 2 다음에 Pod 1가 선택된다는 보장도 없습니다.

주의: iptables는 무작위 분포를 갖는 통계 모듈을 사용합니다. 따라서 균형 조정 알고리즘은 무작위 선택을 기반으로 합니다.

이제 서비스 작동 방식을 이해했으므로 더 흥미로운 서비스 시나리오를 살펴보겠습니다.

Kubernetes의 장기 연결은 기본적으로 확장되지 않습니다.

프런트엔드에서 백엔드로의 각 HTTP 요청은 열리고 닫히는 별도의 TCP 연결을 통해 제공됩니다.

프런트엔드가 백엔드에 초당 100개의 요청을 보내는 경우 100개의 서로 다른 TCP 연결이 열리고 닫힙니다.

하나의 TCP 연결을 열고 모든 후속 HTTP 요청에 이를 사용하여 요청 처리 시간과 로드를 줄일 수 있습니다.

HTTP 프로토콜에는 HTTP 연결 유지 또는 연결 재사용이라는 기능이 있습니다. 이 경우 단일 TCP 연결을 사용하여 여러 HTTP 요청 및 응답을 보내고 받습니다.

이 기능은 기본적으로 활성화되어 있지 않습니다. 서버와 클라이언트를 모두 적절하게 구성해야 합니다.

설정 자체는 간단하고 대부분의 프로그래밍 언어 및 환경에서 접근 가능합니다.

다음은 다양한 언어로 된 예시에 대한 링크입니다.

• Node.js의 연결 유지
• Spring 부트에서 연결 유지
• Python의 연결 유지
• .NET의 연결 유지

Kubernetes 서비스에서 연결 유지를 사용하면 어떻게 되나요?
프런트엔드와 백엔드 모두 연결 유지를 지원한다고 가정해 보겠습니다.

프론트엔드 사본 XNUMX개와 백엔드 사본 XNUMX개가 있습니다. 프런트엔드는 첫 번째 요청을 하고 백엔드에 대한 TCP 연결을 엽니다. 요청이 서비스에 도달하면 백엔드 Pod 중 하나가 대상 주소로 선택됩니다. 백엔드가 응답을 보내고, 프론트엔드가 이를 수신합니다.

응답을 받은 후 TCP 연결이 닫히는 일반적인 상황과 달리 이제는 추가 HTTP 요청을 위해 열린 상태로 유지됩니다.

프런트엔드가 백엔드에 더 많은 요청을 보내면 어떻게 되나요?

이러한 요청을 전달하기 위해 개방형 TCP 연결이 사용되며 모든 요청은 첫 번째 요청이 전달된 동일한 백엔드로 이동됩니다.

iptables가 트래픽을 재분배하면 안 되나요?

이 경우가 아닙니다.

TCP 연결이 생성되면 트래픽이 이동할 특정 백엔드를 선택하는 iptables 규칙을 거칩니다.

모든 후속 요청은 이미 열려 있는 TCP 연결에 있으므로 iptables 규칙은 더 이상 호출되지 않습니다.

어떻게 생겼는지 보자.

1. 첫 번째 Pod는 서비스에 요청을 보냅니다.

   

2. 당신은 다음에 무슨 일이 일어날지 이미 알고 있습니다. 서비스가 존재하지 않지만 요청을 처리하는 iptables 규칙이 있습니다.

   

3. 백엔드 Pod 중 하나가 대상 주소로 선택됩니다.

   

4. 요청이 포드에 도달합니다. 이 시점에서 두 포드 사이에 영구 TCP 연결이 설정됩니다.

   

5. 첫 번째 Pod의 모든 후속 요청은 이미 설정된 연결을 통과합니다.

   

결과적으로 응답 시간이 빨라지고 처리량이 높아지지만 백엔드를 확장하는 능력은 상실됩니다.

백엔드에 두 개의 포드가 있고 지속적인 연결이 있는 경우에도 트래픽은 항상 그 중 하나로 이동합니다.

이 문제를 해결할 수 있습니까?

Kubernetes는 지속적인 연결의 균형을 맞추는 방법을 모르기 때문에 이 작업은 귀하에게 달려 있습니다.

서비스는 엔드포인트라고 불리는 IP 주소와 포트의 모음입니다.

애플리케이션은 서비스에서 엔드포인트 목록을 가져오고 엔드포인트 간에 요청을 배포하는 방법을 결정할 수 있습니다. 각 Pod에 대한 영구 연결을 열고 라운드 로빈을 사용하여 이러한 연결 간의 요청 균형을 조정할 수 있습니다.

아니면 더 신청하세요. 복잡한 밸런싱 알고리즘.

균형 조정을 담당하는 클라이언트측 코드는 다음 논리를 따라야 합니다.

1. 서비스에서 엔드포인트 목록을 가져옵니다.
2. 각 끝점에 대해 영구 연결을 엽니다.
3. 요청을 해야 할 경우 열려 있는 연결 중 하나를 사용하십시오.
4. 끝점 목록을 정기적으로 업데이트하고, 새 끝점을 생성하거나, 목록이 변경되면 기존 영구 연결을 닫습니다.

이것이 다음과 같은 모습일 것입니다.

1. 서비스에 요청을 보내는 첫 번째 Pod 대신 클라이언트 측에서 요청 균형을 조정할 수 있습니다.

   

2. 어떤 포드가 서비스의 일부인지 묻는 코드를 작성해야 합니다.

   

3. 목록이 있으면 클라이언트 측에 저장하고 이를 사용하여 포드에 연결합니다.

   

4. 귀하는 로드 밸런싱 알고리즘을 담당합니다.

   

이제 질문이 생깁니다. 이 문제는 HTTP 연결 유지에만 적용됩니까?

클라이언트 측 로드 밸런싱

HTTP는 지속적인 TCP 연결을 사용할 수 있는 유일한 프로토콜이 아닙니다.

애플리케이션이 데이터베이스를 사용하는 경우 데이터베이스에서 문서를 요청하거나 검색해야 할 때마다 TCP 연결이 열리지 않습니다. 

대신 데이터베이스에 대한 영구 TCP 연결이 열리고 사용됩니다.

데이터베이스가 Kubernetes에 배포되고 액세스가 서비스로 제공되는 경우 이전 섹션에서 설명한 것과 동일한 문제가 발생합니다.

하나의 데이터베이스 복제본이 다른 복제본보다 더 많이 로드됩니다. Kube-proxy와 Kubernetes는 연결 균형을 유지하는 데 도움이 되지 않습니다. 데이터베이스에 대한 쿼리 균형을 유지하도록 주의해야 합니다.

데이터베이스에 연결하는 데 사용하는 라이브러리에 따라 이 문제를 해결하기 위한 다른 옵션이 있을 수 있습니다.

다음은 Node.js에서 MySQL 데이터베이스 클러스터에 액세스하는 예입니다.

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

영구 TCP 연결을 사용하는 다른 프로토콜도 많이 있습니다.

• WebSocket 및 보안 WebSocket
• HTTP / 2
• gRPC
• R소켓
• AMQP

여러분은 이미 이러한 프로토콜의 대부분을 잘 알고 있어야 합니다.

하지만 이러한 프로토콜이 그렇게 인기가 있다면 왜 표준화된 밸런싱 솔루션이 없는 걸까요? 클라이언트 로직을 변경해야 하는 이유는 무엇입니까? 네이티브 Kubernetes 솔루션이 있나요?

Kube-proxy 및 iptables는 Kubernetes에 배포할 때 가장 일반적인 사용 사례를 다루도록 설계되었습니다. 이는 편의를 위한 것입니다.

REST API를 노출하는 웹 서비스를 사용하고 있다면 운이 좋을 것입니다. 이 경우 영구 TCP 연결이 사용되지 않으며 모든 Kubernetes 서비스를 사용할 수 있습니다.

그러나 영구 TCP 연결을 사용하기 시작하면 백엔드 전체에 로드를 균등하게 분산하는 방법을 찾아야 합니다. Kubernetes에는 이 경우에 대해 미리 만들어진 솔루션이 포함되어 있지 않습니다.

그러나 확실히 도움이 될 수 있는 옵션이 있습니다.

Kubernetes에서 장기 연결 균형 조정

Kubernetes에는 네 가지 유형의 서비스가 있습니다.

1. 클러스터IP
2. 노드포트
3. 로드밸런서
4. 목이 없는

처음 세 가지 서비스는 kube-proxy가 iptables 규칙을 구축하는 데 사용하는 가상 IP 주소를 기반으로 작동합니다. 하지만 모든 서비스의 기본 기반은 헤드리스 서비스입니다.

헤드리스 서비스에는 연결된 IP 주소가 없으며 연결된 포드(엔드포인트)의 IP 주소 및 포트 목록을 검색하기 위한 메커니즘만 제공합니다.

모든 서비스는 Headless 서비스를 기반으로 합니다.

ClusterIP 서비스는 다음과 같은 몇 가지 추가 사항이 포함된 헤드리스 서비스입니다. 

1. 관리 계층은 여기에 IP 주소를 할당합니다.
2. Kube-proxy는 필요한 iptables 규칙을 생성합니다.

이렇게 하면 kube-proxy를 무시하고 헤드리스 서비스에서 얻은 엔드포인트 목록을 직접 사용하여 애플리케이션의 로드 밸런싱을 수행할 수 있습니다.

하지만 클러스터에 배포된 모든 애플리케이션에 유사한 논리를 어떻게 추가할 수 있습니까?

애플리케이션이 이미 배포된 경우 이 작업이 불가능해 보일 수 있습니다. 그러나 대체 옵션이 있습니다.

서비스 메시가 도와드리겠습니다

아마도 클라이언트측 로드 밸런싱 전략이 상당히 표준적이라는 점을 이미 알고 계실 것입니다.

애플리케이션이 시작되면 다음이 수행됩니다.

1. 서비스에서 IP 주소 목록을 가져옵니다.
2. 연결 풀을 열고 유지 관리합니다.
3. 끝점을 추가하거나 제거하여 풀을 주기적으로 업데이트합니다.

애플리케이션이 요청을 하고 나면 다음을 수행합니다.

1. 일부 논리(예: 라운드 로빈)를 사용하여 사용 가능한 연결을 선택합니다.
2. 요청을 실행합니다.

이 단계는 WebSocket, gRPC 및 AMQP 연결 모두에 적용됩니다.

이 논리를 별도의 라이브러리로 분리하여 애플리케이션에서 사용할 수 있습니다.

그러나 Istio 또는 Linkerd와 같은 서비스 메시를 대신 사용할 수 있습니다.

Service Mesh는 다음과 같은 프로세스를 통해 애플리케이션을 강화합니다.

1. 서비스 IP 주소를 자동으로 검색합니다.
2. WebSocket 및 gRPC와 같은 연결을 확인합니다.
3. 올바른 프로토콜을 사용하여 요청의 균형을 유지합니다.

Service Mesh는 클러스터 내의 트래픽을 관리하는 데 도움이 되지만 리소스 집약적입니다. 다른 옵션으로는 Netflix Ribbon과 같은 타사 라이브러리나 Envoy와 같은 프로그래밍 가능한 프록시를 사용하는 것이 있습니다.

균형 문제를 무시하면 어떻게 되나요?

로드 밸런싱을 사용하지 않도록 선택해도 여전히 변경 사항을 확인할 수 없습니다. 몇 가지 작업 시나리오를 살펴보겠습니다.

서버보다 클라이언트가 더 많다면 이는 큰 문제가 되지 않습니다.

두 개의 서버에 연결되는 다섯 개의 클라이언트가 있다고 가정해 보겠습니다. 균형 조정이 없더라도 두 서버가 모두 사용됩니다.

연결이 균등하게 분배되지 않을 수 있습니다. XNUMX개의 클라이언트가 동일한 서버에 연결되어 있을 수 있지만 두 서버가 모두 사용될 가능성이 높습니다.

더 문제는 반대 상황이다.

클라이언트 수가 적고 서버 수가 많으면 리소스 활용도가 낮아질 수 있으며 잠재적인 병목 현상이 나타날 수 있습니다.

두 개의 클라이언트와 다섯 개의 서버가 있다고 가정해 보겠습니다. 가장 좋은 경우에는 XNUMX개의 서버 중 XNUMX개의 서버에 대한 XNUMX개의 영구 연결이 있을 것입니다.

나머지 서버는 유휴 상태가 됩니다.

이 두 서버가 클라이언트 요청을 처리할 수 없는 경우 수평적 확장은 도움이 되지 않습니다.

결론

Kubernetes 서비스는 대부분의 표준 웹 애플리케이션 시나리오에서 작동하도록 설계되었습니다.

그러나 데이터베이스, gRPC 또는 WebSocket과 같은 영구 TCP 연결을 사용하는 애플리케이션 프로토콜로 작업을 시작하면 서비스가 더 이상 적합하지 않습니다. Kubernetes는 영구 TCP 연결의 균형을 유지하기 위한 내부 메커니즘을 제공하지 않습니다.

이는 클라이언트측 균형을 염두에 두고 애플리케이션을 작성해야 함을 의미합니다.

팀에서 준비한 번역 Mail.ru의 Kubernetes aaS.

주제에 대해 더 읽을 내용:

1. Kubernetes의 세 가지 수준의 자동 확장 및 이를 효과적으로 사용하는 방법. 
2. 구현을 위한 템플릿을 갖춘 불법 복제 정신의 Kubernetes.
3. 디지털 혁신에 관한 텔레그램 채널.

출처 : habr.com