Kubernetes 클러스터 설계: 몇 개가 있어야 합니까?

메모. 번역: 이 자료는 교육 프로젝트에서 나온 것입니다. learnk8s Kubernetes 기반 인프라를 설계할 때 자주 묻는 질문에 대한 답변입니다. 각 옵션의 장단점에 대한 상당히 자세한 설명이 귀하의 프로젝트에 가장 적합한 선택을 하는 데 도움이 되기를 바랍니다.

TL; DR: 동일한 워크로드 세트가 여러 개의 대규모 클러스터(각 클러스터에는 많은 수의 워크로드가 있음) 또는 여러 소규모 클러스터(각 클러스터의 로드 수가 적음)에서 실행될 수 있습니다.

다음은 각 접근 방식의 장단점을 평가한 표입니다.

Kubernetes를 애플리케이션 실행을 위한 플랫폼으로 사용할 때 클러스터 설정의 복잡성에 대한 몇 가지 근본적인 질문이 종종 발생합니다.

• 클러스터를 몇 개 사용해야 합니까?
• 얼마나 크게 만들어야 하나요?
• 각 클러스터에는 무엇이 포함되어야 합니까?

이 기사에서는 각 접근 방식의 장단점을 분석하여 이러한 모든 질문에 답하려고 합니다.

질문의 진술

소프트웨어 개발자로서 당신은 동시에 많은 애플리케이션을 개발하고 운영할 가능성이 높습니다.

또한 이러한 애플리케이션의 많은 인스턴스는 서로 다른 환경에서 실행될 가능성이 높습니다. DEV, test и 찌르다.

그 결과는 애플리케이션과 환경의 전체 매트릭스입니다.

애플리케이션 및 환경

위의 예는 3개의 애플리케이션과 3개의 환경을 나타내므로 총 9개의 가능한 옵션이 있습니다.

각 애플리케이션 인스턴스는 다른 애플리케이션 인스턴스와 독립적으로 작업할 수 있는 독립형 배포 단위입니다.

참고 애플리케이션 인스턴스 다수로 구성될 수 있음 구성 요소들, 프론트엔드, 백엔드, 데이터베이스 등과 같은 마이크로서비스 애플리케이션의 경우 인스턴스에는 모든 마이크로서비스가 포함됩니다.

결과적으로 Kubernetes 사용자에게는 다음과 같은 몇 가지 질문이 있습니다.

• 모든 애플리케이션 인스턴스를 하나의 클러스터에 배치해야 합니까?
• 각 애플리케이션 인스턴스에 대해 별도의 클러스터를 갖는 것이 가치가 있습니까?
• 아니면 위의 접근 방식을 조합하여 사용해야 합니까?

Kubernetes는 사용자의 능력을 제한하지 않는 유연한 시스템이므로 이러한 모든 옵션은 매우 실행 가능합니다.

가능한 방법은 다음과 같습니다.

• 하나의 큰 공통 클러스터;
• 많은 소규모 고도로 전문화된 클러스터;
• 애플리케이션당 하나의 클러스터;
• 환경당 하나의 클러스터.

아래에 표시된 것처럼 처음 두 가지 접근 방식은 옵션 규모의 반대쪽 끝에 있습니다.

몇 개의 큰 클러스터(왼쪽)부터 여러 개의 작은 클러스터(오른쪽)까지

일반적으로 노드와 포드의 합이 더 많으면 한 클러스터가 다른 클러스터보다 "더 큰" 것으로 간주됩니다. 예를 들어, 10개의 노드와 100개의 포드가 있는 클러스터는 1개의 노드와 10개의 포드가 있는 클러스터보다 큽니다.

자, 시작해 봅시다!

1. 하나의 대규모 공통 클러스터

첫 번째 옵션은 모든 워크로드를 하나의 클러스터에 배치하는 것입니다.

하나의 큰 클러스터

이 접근 방식 내에서 클러스터는 범용으로 사용됩니다. 인프라 플랫폼 — 기존 Kubernetes 클러스터에 필요한 모든 것을 배포하기만 하면 됩니다.

네임스페이스 Kubernetes를 사용하면 클러스터의 일부를 논리적으로 서로 분리할 수 있으므로 각 애플리케이션 인스턴스가 자체 네임스페이스를 가질 수 있습니다.

이 접근 방식의 장점과 단점을 살펴보겠습니다.

+ 자원의 효율적인 사용

단일 클러스터를 사용하면 Kubernetes 클러스터를 실행하고 관리하는 데 필요한 모든 리소스의 복사본 하나만 필요합니다.

예를 들어 마스터 노드의 경우에도 마찬가지입니다. 일반적으로 각 Kubernetes 클러스터에는 3개의 마스터 노드가 있으므로 단일 클러스터의 경우 그 수는 그대로 유지됩니다(비교를 위해 10개의 클러스터에는 30개의 마스터 노드가 필요함).

위의 세부 사항은 로드 밸런서, 수신 컨트롤러, 인증, 로깅 및 모니터링 시스템과 같이 전체 클러스터에서 작동하는 다른 서비스에도 적용됩니다.

단일 클러스터에서는 이러한 모든 서비스를 모든 워크로드에 대해 한 번에 사용할 수 있습니다(여러 클러스터의 경우처럼 복사본을 만들 필요가 없음).

+ 저렴하다

위의 결과로 간접 비용이 없기 때문에 일반적으로 더 적은 수의 클러스터가 더 저렴합니다.

이는 호스팅 방식(온프레미스 또는 클라우드)에 관계없이 상당한 비용이 소요될 수 있는 마스터 노드의 경우 특히 그렇습니다.

다음과 같은 일부 관리형 Kubernetes 서비스 Google 쿠버네티스 엔진(GKE) 또는 AKS (Azure Kubernetes Service), 제어 레이어를 무료로 제공합니다. 이 경우 비용 문제는 덜 심각합니다.

각 Kubernetes 클러스터의 운영에 대해 고정 요금을 부과하는 관리형 서비스도 있습니다(예: Amazon Elastic Kubernetes Service, EKS).

+ 효율적인 관리

여러 클러스터를 관리하는 것보다 하나의 클러스터를 관리하는 것이 더 쉽습니다.

관리에는 다음 작업이 포함될 수 있습니다.

• Kubernetes 버전 업데이트;
• CI/CD 파이프라인 설정
• CNI 플러그인 설치;
• 사용자 인증 시스템을 설정하는 단계;
• 액세스 컨트롤러 설치;

그리고 많은 다른 사람들…

클러스터가 하나인 경우 이 모든 작업을 한 번만 수행하면 됩니다.

많은 클러스터의 경우 작업을 여러 번 반복해야 하며, 이를 위해서는 프로세스의 일관성과 일관성을 보장하기 위해 프로세스와 도구의 일부 자동화가 필요할 수 있습니다.

그리고 이제 단점에 대해 몇 마디.

− 단일 실패 지점

거절의 경우 유일한 클러스터 작동이 즉시 중지됩니다. 모든 작업량!

상황이 잘못될 수 있는 경우는 여러 가지가 있습니다.

• Kubernetes를 업데이트하면 예상치 못한 부작용이 발생합니다.
• 클러스터 전체 구성 요소(예: CNI 플러그인)가 예상대로 작동하지 않기 시작합니다.
• 클러스터 구성 요소 중 하나가 올바르게 구성되지 않았습니다.
• 기본 인프라에 장애가 발생했습니다.

이러한 사고는 공유 클러스터에서 호스팅되는 모든 작업 부하에 심각한 손상을 초래할 수 있습니다.

− 견고한 절연체가 없음

공유 클러스터에서 실행된다는 것은 응용 프로그램이 클러스터 노드의 하드웨어, 네트워킹 기능 및 운영 체제를 공유한다는 것을 의미합니다.

어떤 의미에서 동일한 노드에서 실행되는 두 개의 서로 다른 애플리케이션이 있는 두 개의 컨테이너는 동일한 OS 커널을 실행하는 동일한 시스템에서 실행되는 두 개의 프로세스와 같습니다.

Linux 컨테이너는 일종의 격리 기능을 제공하지만 가상 머신에서 제공하는 것만큼 강력하지는 않습니다. 본질적으로 컨테이너의 프로세스는 호스트 운영 체제에서 실행되는 프로세스와 동일합니다.

이는 보안 문제가 될 수 있습니다. 이론적으로 이러한 배열은 관련되지 않은 응용 프로그램이 (의도적이든 우발적이든) 서로 통신할 수 있도록 허용합니다.

또한 Kubernetes 클러스터의 모든 워크로드는 다음과 같은 일부 클러스터 전체 서비스를 공유합니다. DNS - 이를 통해 애플리케이션은 클러스터에 있는 다른 애플리케이션의 서비스를 찾을 수 있습니다.

위의 모든 사항은 애플리케이션 보안 요구 사항에 따라 다른 의미를 가질 수 있습니다.

Kubernetes는 다음과 같은 보안 문제를 방지하기 위한 다양한 도구를 제공합니다. PodSecurity정책 и 네트워크 정책. 그러나 올바르게 설정하려면 약간의 경험이 필요하며 모든 보안 허점을 완전히 막을 수는 없습니다.

Kubernetes는 원래 Kubernetes를 위해 설계되었다는 점을 항상 기억하는 것이 중요합니다. 나누는, 아닙니다 격리와 안전.

− 엄격한 다중 테넌시 부족

Kubernetes 클러스터에 공유 리소스가 풍부하기 때문에 서로 다른 애플리케이션이 서로의 발가락을 밟을 수 있는 방법은 많습니다.

예를 들어, 애플리케이션은 공유 리소스(예: CPU 또는 메모리)를 독점하고 동일한 노드에서 실행되는 다른 애플리케이션이 이에 액세스하는 것을 거부할 수 있습니다.

Kubernetes는 다음과 같이 이 동작을 제어하는 ​​다양한 메커니즘을 제공합니다. 리소스 요청 및 제한 (“기사 참조) Kubernetes의 CPU 제한 및 공격적인 조절 " - 약. 번역), 리소스할당량 и 한도 범위. 그러나 보안의 경우와 마찬가지로 해당 구성은 매우 간단하며 예상치 못한 모든 부작용을 완전히 방지할 수는 없습니다.

− 사용자 수가 많다

단일 클러스터의 경우 많은 사람들에게 접근권을 열어주어야 합니다. 그리고 그 수가 많을수록 무언가를 "파괴"할 위험이 높아집니다.

클러스터 내에서 다음을 사용하여 누가 무엇을 할 수 있는지 제어할 수 있습니다. 역할 기반 액세스 제어(RBAC) (“기사 참조) Kubernetes의 사용자 및 권한 부여 RBAC " - 약. 번역). 그러나 사용자가 자신의 책임 영역 내에서 무언가를 "파괴"하는 것을 막지는 못합니다.

− 클러스터는 무한정 커질 수 없습니다.

모든 워크로드에 사용되는 클러스터는 상당히 클 가능성이 높습니다(노드 및 포드 수 측면에서).

그러나 여기서 또 다른 문제가 발생합니다. Kubernetes의 클러스터는 무한정 커질 수 없습니다.

클러스터 크기에는 이론적인 제한이 있습니다. Kubernetes에서는 대략 다음과 같습니다. 노드 5000개, 포드 150만개, 컨테이너 300만개.

그러나 실제 생활에서는 문제가 훨씬 더 일찍 시작될 수 있습니다. 500노트.

사실 대규모 클러스터는 Kubernetes 제어 계층에 높은 로드를 배치합니다. 즉, 클러스터를 효율적으로 가동하고 실행하려면 세심한 조정이 필요합니다.

이 문제는 "라는 원래 블로그의 관련 기사에서 조사되었습니다.Kubernetes 클러스터 설계 — 작업자 노드 크기 선택".

그러나 반대 접근 방식인 많은 작은 클러스터를 고려해 보겠습니다.

2. 다수의 소규모 전문 클러스터

이 접근 방식을 사용하면 배포하는 각 요소에 대해 별도의 클러스터를 사용합니다.

많은 작은 클러스터

이 기사의 목적에 따라 배포 가능한 요소 애플리케이션의 인스턴스(예: 별도 애플리케이션의 개발 버전)를 나타냅니다.

이 전략에서는 Kubernetes를 특화된 솔루션으로 사용합니다. 실행 시간 개별 애플리케이션 인스턴스의 경우.

이 접근 방식의 장점과 단점을 살펴보겠습니다.

+ 제한된 "폭발 반경"

클러스터에 장애가 발생하면 부정적인 결과는 해당 클러스터에 배포된 워크로드에만 국한됩니다. 다른 모든 워크로드는 그대로 유지됩니다.

+ 단열재

개별 클러스터에 호스팅된 워크로드는 프로세서, 메모리, 운영 체제, 네트워크 또는 기타 서비스와 같은 리소스를 공유하지 않습니다.

그 결과, 관련되지 않은 애플리케이션 간의 긴밀한 격리가 이루어지며 이는 보안에 도움이 될 수 있습니다.

+ 소수의 사용자

각 클러스터에는 제한된 워크로드 세트만 포함되어 있으므로 클러스터에 액세스할 수 있는 사용자 수가 줄어듭니다.

클러스터에 액세스할 수 있는 사람이 적을수록 무언가가 "중단"될 위험이 낮아집니다.

단점을 살펴 보겠습니다.

− 자원의 비효율적 사용

앞서 언급했듯이 각 Kubernetes 클러스터에는 마스터 노드, 제어 계층 구성 요소, 모니터링 및 로깅 솔루션 등 특정 관리 리소스 세트가 필요합니다.

소규모 클러스터 수가 많은 경우 관리에 더 많은 리소스를 할당해야 합니다.

− 비싸다

자원을 비효율적으로 사용하면 자동으로 높은 비용이 발생합니다.

예를 들어, 동일한 컴퓨팅 성능으로 30개가 아닌 XNUMX개의 마스터 노드를 유지하면 필연적으로 비용에 영향을 미칩니다.

− 행정상의 어려움

여러 Kubernetes 클러스터를 관리하는 것은 하나만 관리하는 것보다 훨씬 어렵습니다.

예를 들어 각 클러스터에 대한 인증 및 권한 부여를 구성해야 합니다. Kubernetes 버전도 여러 번 업데이트해야 합니다.

이러한 모든 작업을 보다 효율적으로 수행하려면 자동화를 사용해야 할 가능성이 높습니다.

이제 덜 극단적인 시나리오를 살펴보겠습니다.

3. 애플리케이션당 하나의 클러스터

이 접근 방식에서는 특정 애플리케이션의 모든 인스턴스에 대해 별도의 클러스터를 만듭니다.

애플리케이션당 클러스터

이 경로는 "원칙의 일반화로 간주될 수 있습니다.팀당 별도의 클러스터”, 일반적으로 엔지니어 팀이 하나 이상의 애플리케이션을 개발하기 때문입니다.

이 접근 방식의 장점과 단점을 살펴보겠습니다.

+ 클러스터는 애플리케이션에 맞게 조정 가능

애플리케이션에 특별한 요구 사항이 있는 경우 다른 클러스터에 영향을 주지 않고 클러스터에서 구현할 수 있습니다.

이러한 요구 사항에는 GPU 작업자, 특정 CNI 플러그인, 서비스 메시 또는 기타 서비스가 포함될 수 있습니다.

각 클러스터는 필요한 것만 포함하도록 클러스터에서 실행되는 애플리케이션에 맞게 조정할 수 있습니다.

− 하나의 클러스터 내 다양한 ​​환경

이 접근 방식의 단점은 서로 다른 환경의 애플리케이션 인스턴스가 동일한 클러스터에 공존한다는 것입니다.

예를 들어 애플리케이션의 prod 버전은 dev 버전과 동일한 클러스터에서 실행됩니다. 이는 또한 개발자가 애플리케이션의 프로덕션 버전이 운영되는 동일한 클러스터에서 작업한다는 것을 의미합니다.

개발자의 작업이나 개발 버전의 결함으로 인해 클러스터에서 오류가 발생하면 프로덕션 버전도 잠재적으로 어려움을 겪을 수 있습니다. 이는 이 접근 방식의 큰 단점입니다.

그리고 마지막으로 우리 목록의 마지막 시나리오입니다.

4. 환경당 하나의 클러스터

이 시나리오에는 각 환경에 대해 별도의 클러스터를 할당하는 작업이 포함됩니다.

환경당 클러스터 XNUMX개

예를 들어 클러스터가 있을 수 있습니다. DEV, test и 찌르다, 특정 환경 전용 애플리케이션의 모든 인스턴스를 실행합니다.

이 접근 방식의 장점과 단점은 다음과 같습니다.

+ 프로덕션 환경 격리

이 접근 방식에서는 모든 환경이 서로 격리됩니다. 그러나 실제로 이는 프로덕션 환경에서 특히 중요합니다.

애플리케이션의 프로덕션 버전은 이제 다른 클러스터 및 환경에서 발생하는 상황과 독립적입니다.

이렇게 하면 개발 클러스터에서 갑자기 문제가 발생하더라도 애플리케이션의 prod 버전은 아무 일도 없었던 것처럼 계속 작동합니다.

+ 클러스터는 환경에 맞게 조정 가능

각 클러스터는 해당 환경에 맞게 조정될 수 있습니다. 예를 들어 다음을 수행할 수 있습니다.

• 개발 클러스터에 개발 및 디버깅을 위한 도구를 설치합니다.
• 클러스터에 테스트 프레임워크 및 도구 설치 test;
• 클러스터에서 보다 강력한 하드웨어 및 네트워크 채널을 사용합니다. 찌르다.

이를 통해 애플리케이션 개발과 운영 모두의 효율성을 높일 수 있습니다.

+ 프로덕션 클러스터에 대한 액세스 제한

프로덕션 클러스터와 직접 작업해야 할 필요성은 거의 발생하지 않으므로 액세스할 수 있는 사람들의 범위를 크게 제한할 수 있습니다.

더 나아가서 이 클러스터에 대한 사람들의 액세스를 완전히 거부하고 자동화된 CI/CD 도구를 사용하여 모든 배포를 수행할 수 있습니다. 이러한 접근 방식은 가장 관련성이 높은 부분에서 인적 오류의 위험을 최소화합니다.

그리고 이제 단점에 대해 몇 마디.

− 애플리케이션 간 격리 없음

이 접근 방식의 가장 큰 단점은 애플리케이션 간의 하드웨어 및 리소스 격리가 부족하다는 것입니다.

관련되지 않은 애플리케이션은 시스템 코어, 프로세서, 메모리 및 기타 서비스와 같은 클러스터 리소스를 공유합니다.

언급했듯이 이는 잠재적으로 위험할 수 있습니다.

− 애플리케이션 종속성을 현지화할 수 없음

애플리케이션에 특별한 요구 사항이 있는 경우 모든 클러스터에서 해당 요구 사항을 충족해야 합니다.

예를 들어 애플리케이션에 GPU가 필요한 경우 각 클러스터에는 GPU가 있는 작업자가 하나 이상 포함되어야 합니다(해당 애플리케이션에서만 사용되는 경우에도 마찬가지).

결과적으로 비용이 증가하고 자원이 비효율적으로 사용될 위험이 있습니다.

결론

특정 애플리케이션 세트가 있는 경우 여러 개의 대규모 클러스터 또는 여러 개의 소규모 클러스터에 배치할 수 있습니다.

이 기사에서는 하나의 글로벌 클러스터부터 여러 개의 소규모 고도로 전문화된 클러스터에 이르기까지 다양한 접근 방식의 장단점을 설명합니다.

• 하나의 큰 일반 클러스터;
• 많은 소규모 고도로 전문화된 클러스터;
• 애플리케이션당 하나의 클러스터;
• 환경당 하나의 클러스터.

그렇다면 어떤 접근 방식을 취해야 할까요?

항상 그렇듯이 대답은 사용 사례에 따라 다릅니다. 다양한 접근 방식의 장단점을 비교하고 가장 최적의 옵션을 선택해야 합니다.

그러나 선택은 위의 예에만 국한되지 않고 원하는 대로 조합하여 사용할 수 있습니다!

예를 들어, 각 팀에 대해 두 개의 클러스터, 즉 개발 클러스터(환경이 있을 것임)를 구성할 수 있습니다. DEV и test) 및 클러스터 생산 (프로덕션 환경이 위치할 위치)

이 문서의 정보를 기반으로 특정 시나리오에 따라 장단점을 최적화할 수 있습니다. 행운을 빌어요!

PS

블로그에서도 읽어보세요.

• «Kubernetes 문제 해결을 위한 시각적 가이드";
• «현재 Kubernetes에 로그인하는 것(그뿐만 아니라): 기대와 현실";
• «Service Mesh: 최신 기술에 대해 모든 소프트웨어 엔지니어가 알아야 할 사항";
• «Kubernetes 보안의 ABC: 인증, 권한 부여, 감사".

출처 : habr.com